Comments 48
С интернетом вещей, меш сетями дела не имел и мало что в этой области знаю, но.
Я не понимаю, зачем вы пилите софт под киты и т.д., если сейчас у всех есть как минимум один устаревший смартфон, с более мощным железом, USB, BT, WIFI, экраном и все это помещается в одной руке.
Может я ошибаюсь, но как по мне малинка и адуино прикольные как для обучения, помигать светодиодами, может что по сложнее.
Написать бы мелкую операционку на Линукс ядре, что бы просто взял какой нить смарт на андроиде, поставил на зарядку, залил прошивку и меш ячейка готова, а там может по желанию торрент качалку запустить.
P.S. Губу уже закатил)
Я не понимаю, зачем вы пилите софт под киты и т.д., если сейчас у всех есть как минимум один устаревший смартфон, с более мощным железом, USB, BT, WIFI, экраном и все это помещается в одной руке.
Может я ошибаюсь, но как по мне малинка и адуино прикольные как для обучения, помигать светодиодами, может что по сложнее.
Написать бы мелкую операционку на Линукс ядре, что бы просто взял какой нить смарт на андроиде, поставил на зарядку, залил прошивку и меш ячейка готова, а там может по желанию торрент качалку запустить.
P.S. Губу уже закатил)
Версия под андройд (точнее кастомная сборка) в планах есть. Мы сейчас решили сделать первый шаг с Линукс ОС просто потому что Rasbery Pie откопать можно сравнительно быстро и не дорого
Я просто представляю этот проект меш-сети в более масштабном варианте, в случае жестких ограничений в обычном инете.
Например, я живу в Горловке на Донбассе в условиях гражданской войны, что мне проще достать, устаревший смартфон 2010 года или какой-то Rasbery Pie который если и завезут то втридорога?
Плюсы смартфонов в качестве меш ячейки зашкаливают.
Будь возможность, я бы конечно сам собрал, это намного интересней)
Например, я живу в Горловке на Донбассе в условиях гражданской войны, что мне проще достать, устаревший смартфон 2010 года или какой-то Rasbery Pie который если и завезут то втридорога?
Плюсы смартфонов в качестве меш ячейки зашкаливают.
Будь возможность, я бы конечно сам собрал, это намного интересней)
В данной реализации есть не большой плюс над телефоном. Радио чип LoRa в радиусе до 1 км отлично себя показывает. Но в ваших условиях мобильный телефон будет действительно лучше. Есть приложение Firechat, может оно будет полезно.
На Донбассе эти сети поднимать просто некому. Логично стартовать, охватив как можно более широкую аудиторию. И раз уж на то пошло, старых компьютеров куда больше, чем старых ведрофонов, а сами компьютеры гораздо более гибкие.
Да поднимать некому, наверное просто потому что нет необходимости, пока что.
Старых компьютеров больше, но зачастую их просто сдают на запчасти ибо практической пользы от них уже очень мало, а вот старые смартфоны откладывают в «долгий ящик» практически все, из простого принципа «авось основной сломается так старый возьму».
Если речь идет об обычных системниках, то у них 3 основных минуса, размеры, отсутствие встроенного Wifi и аккумулятора, ноутбуки конечно всех обыгрывают)
Старых компьютеров больше, но зачастую их просто сдают на запчасти ибо практической пользы от них уже очень мало, а вот старые смартфоны откладывают в «долгий ящик» практически все, из простого принципа «авось основной сломается так старый возьму».
Если речь идет об обычных системниках, то у них 3 основных минуса, размеры, отсутствие встроенного Wifi и аккумулятора, ноутбуки конечно всех обыгрывают)
Допустим существует эта легкая меш-операционка на линукс ядре и есть 10к добровольцев.
Например, один доброволец на одну многоэтажку, он берет свой смартфон и по инструкции заливает прошивку, затем в хорошо изолированной пластиковой бутылке закрепляет на крыше.
Питание для смартфона из зарядного можно подключить через заброшенный антенный коаксиальный кабель.
Исходя что в смартах слабые Wifi модули, вероятно лучше всего ставить их на крышу каждого дома, дома стоят относительно близко.
Вот и профит)
Например, один доброволец на одну многоэтажку, он берет свой смартфон и по инструкции заливает прошивку, затем в хорошо изолированной пластиковой бутылке закрепляет на крыше.
Питание для смартфона из зарядного можно подключить через заброшенный антенный коаксиальный кабель.
Исходя что в смартах слабые Wifi модули, вероятно лучше всего ставить их на крышу каждого дома, дома стоят относительно близко.
Вот и профит)
Аккумулятор в таких условиях, конечно, действительно необходим. Об этом не подумал. Тут еще энергопотребление компьютеров к минусам можно отнести тогда. В случае обрыва ЛЭП или проблем с подстанциями, это ударит даже сильнее, чем отсутствие аккумулятора, потому что аккумулятор можно сколхозить.
Старые системники еще, кроме указанных минусов, обладают еще несколькими: в них нет блютуза, вафли, т.е. эти интерфейсы надо докупать (доп. траты), они шумные, и они потребляют прилично электричества (в десятки раз больше смартфона).
Ну и помимо перечисленных недостатков у уже имеющихся протоколов есть еще и фатальный?
FreeRTOS довольно жирная РТОС, рассматривались ли другие РТОС?
ChibiOS, Contiki, RIOT
ChibiOS, Contiki, RIOT
тема интересная но cтатья мало что раскрывает.
- зачем там GPS? ноды будут подвижные?
- чем ваш решение лучше других? почему вы написали свою систему маршрутизации, а не взяли существующие?
- почему нет солнечной панели? аккумулятор долго не проживет.
- почему lora, а не wifi? как в сеть с мобильного подключатся?
- вы не пробовали делать на ESP8266? можно сделать много очень дешовых нод и раскидать по территории.
1. Да, стек заточен под динамические системы.
2. В рамках Open Source DevKit будет возможность реализовывать собственные протоколы маршрутизации. Наше главное отличие это фокус на динамические сети, в которых маршрут постоянно перестраивается, поэтому мы минимизируем размеры таблицы маршрутизации.
3. Представленная нами нода была собрана под нужды тестирования и разработки. Добавить солнечную батарею можно, но пусть это сделают профессионалы.
4. При релизе мы заложим поддержку wi-fi + lora. Для связи нужно будет написать приложение на телефон.
5. Под ESP8266 есть рабочий проект который мы возили на SLUSH. Но там есть сложности в публикации под Open Source. Если интересно ESP на одной банке лития проработала больше 24 часов общаясь и моргая светодиодом. Если интересно могу больше деталей про ESP с фото представить после релиза.
2. В рамках Open Source DevKit будет возможность реализовывать собственные протоколы маршрутизации. Наше главное отличие это фокус на динамические сети, в которых маршрут постоянно перестраивается, поэтому мы минимизируем размеры таблицы маршрутизации.
3. Представленная нами нода была собрана под нужды тестирования и разработки. Добавить солнечную батарею можно, но пусть это сделают профессионалы.
4. При релизе мы заложим поддержку wi-fi + lora. Для связи нужно будет написать приложение на телефон.
5. Под ESP8266 есть рабочий проект который мы возили на SLUSH. Но там есть сложности в публикации под Open Source. Если интересно ESP на одной банке лития проработала больше 24 часов общаясь и моргая светодиодом. Если интересно могу больше деталей про ESP с фото представить после релиза.
Поддержка iC880A-SPI будет 23 декабря?
Ну и чем ваша разработка лучше ZigBee например?
1. Наша разработка независима от конкретного физического (и не только физического) интерфейса. При наличии соответствующих интерфейсных уровней можем работать и через LoRa, и через WiFi, и через BLE, и через ещё что-нибудь.
2. ZigBee выделяет какую-то из нод в качестве маршрутизатора; нагрузка на эту ноду резко возрастает, поскольку ей необходимо полностью маршрутизировать всю сеть в зоне своей ответственности, из-за чего нода может слишком быстро разрядиться. После её отключения то же самое происходит с другой нодой. И так далее.
3. Ключи шифрования не хранятся на координаторе. Никакого координатора у нас вообще нет.
2. ZigBee выделяет какую-то из нод в качестве маршрутизатора; нагрузка на эту ноду резко возрастает, поскольку ей необходимо полностью маршрутизировать всю сеть в зоне своей ответственности, из-за чего нода может слишком быстро разрядиться. После её отключения то же самое происходит с другой нодой. И так далее.
3. Ключи шифрования не хранятся на координаторе. Никакого координатора у нас вообще нет.
Координатор, чаще всего, является нодой с постоянным питанием и большими ресурсами. Проблема его разрядки, обычно, не возникает.
Это да, но возникает проблема с таймслотами, как бы сама собой :)
Речь шла про питание маршрутизаторов. И если маршрутизатор — узел с постоянным питанием, то он перестаёт быть мобильным, а наше решение, как уже упоминалось, рассчитано на полностью динамические сети — то есть такие, где и маршрутизаторы вынуждены (непредсказуемо) менять своё положение.
Я, собственно, вот про что. С прошествием некоторого периода времени батарейки на мобильных узлах-ретрансляторах садятся. Никто их не будет менять периодически (давайте смотреть на вещи трезво). Поэтому весь трафик — включая синхронизацию времени — пойдет через стационарные узлы, а не в обход их по кратчайшему пути. Отсюда забивание таймслотов.
Следующий этап радости — высаживание батареек мобильных узлов вблизи этих сетей, которые маршрутизируют трафик через эти узлы. Сеть не упадет, нет. Просто более удаленные узлы будут пытаться связаться с маршрутизатором напрямую, отчего резко поползет вверх количество битых пакетов и повторов, а это опять же занятые таймслоты.
Это опыт на сети из 40 устройств на MSP430 c батарейками 2032 и трансиверами сс2420. У нас, правда, была несколько другая задача — организовать трафик внутри большого здания
Следующий этап радости — высаживание батареек мобильных узлов вблизи этих сетей, которые маршрутизируют трафик через эти узлы. Сеть не упадет, нет. Просто более удаленные узлы будут пытаться связаться с маршрутизатором напрямую, отчего резко поползет вверх количество битых пакетов и повторов, а это опять же занятые таймслоты.
Это опыт на сети из 40 устройств на MSP430 c батарейками 2032 и трансиверами сс2420. У нас, правда, была несколько другая задача — организовать трафик внутри большого здания
Да, в таком случае обычные PAN решения плохо сработают.
API в виде сокетов действительно удобнее. Когда мы писали 802.15.4, тоже пришли к сокетному API для приложений.
Кстати говоря, а почему вы выбрали WAN-решение?
Инструкция по сборке ноды образцовая.
Пролистал 18 страниц PDF документа с упоением.
Пролистал 18 страниц PDF документа с упоением.
Как-то надо ввести дифференцированные названия для «Интернета вещей» в зависимости от сложности и фичесодержания. Например, у меня система датчиков, умных розеток, светильников и проч. живет в mesh-сети. При этом умещается в восьмибитные МК с размером флеша 8/16/32КБ. Есть конечные узлы, есть маршрутизирующие, присутствует шифрование и авторизация. Это сильно отличается от приведенного в статье, хотя и то и это можно считать IoTом.
Насколько мы понимаем, наше решение несколько отличается от Вашего с идейной точки зрения:
1. Вероятно, используемая Вами система рассчитана на домашнее применение, а потому имеет некоторые ограничения, позволяющие её упростить (не нужно связывать ноды, скажем, на расстоянии 500 метров).
2. Мы принципиально отказались от разделения ролей узлов.
3. Мы поддерживаем любой нижележащий интерфейс (как физический, так и нет), и даже несколько разных одновременно. Разумеется, библиотека интерфейса должна отвечать некоторым требованиям, но это лишь один модуль нашего стека, а не весь стек.
4. Указанные нами требования включают в себя, помимо стека, саму ОС, и при этом ещё остаётся достаточно свободных ресурсов для пользовательского приложения или даже нескольких.
Так что Вы правы, и наше, и Ваше решения — IoT, но разного предназначения. Полагаю, история сама «раздаст» подходящие названия для соответствующих категорий.
1. Вероятно, используемая Вами система рассчитана на домашнее применение, а потому имеет некоторые ограничения, позволяющие её упростить (не нужно связывать ноды, скажем, на расстоянии 500 метров).
2. Мы принципиально отказались от разделения ролей узлов.
3. Мы поддерживаем любой нижележащий интерфейс (как физический, так и нет), и даже несколько разных одновременно. Разумеется, библиотека интерфейса должна отвечать некоторым требованиям, но это лишь один модуль нашего стека, а не весь стек.
4. Указанные нами требования включают в себя, помимо стека, саму ОС, и при этом ещё остаётся достаточно свободных ресурсов для пользовательского приложения или даже нескольких.
Так что Вы правы, и наше, и Ваше решения — IoT, но разного предназначения. Полагаю, история сама «раздаст» подходящие названия для соответствующих категорий.
Может стоит попробовать Raspberry Pi Zero? Он, в принципе, доступен — 12$/шт у перекупщиков в Штатах + 40$ пересылка. На 5 штук получается по 20$ за штуку, я себе привез недавно. Zero сильно меньше кушают, например, пиковое потребление на загрузке — 0,18А. Ну и размеры, само собой — можно в тот же объем запихать еще пару 18650.
Упомянутые устройства на основе Raspberry Pi — в первую очередь тестовые, и в них нам важнее было не оптимизировать цену или какие-то аналогичные факторы, а обеспечить удобство разработки и расширяемость. Кроме того, Raspberry Pi 2B уже были у нас под рукой, тогда как Zero пришлось бы заказывать и ждать.
Thread Group же есть и 6LowPAN
Как уже было упомянуто (правда, иными словами), мы поставили перед собой задачу несколько более сложную и общую, чем условно-простое обеспечение mesh в рамках одного дома или одной квартиры. А Thread Guard, по их собственному указанию, предназначен исключительно для такого применения.
6LoWPAN также имеет несколько отличающуюся идею в своём основании: эти сети работают исключительно на одном типе интерфейса, тогда как мы стараемся не привязываться к конкретному типу физического интерфейса. В некотором смысле, мы хотим не «победить» другие решения, а подружить их между собой.
6LoWPAN также имеет несколько отличающуюся идею в своём основании: эти сети работают исключительно на одном типе интерфейса, тогда как мы стараемся не привязываться к конкретному типу физического интерфейса. В некотором смысле, мы хотим не «победить» другие решения, а подружить их между собой.
Тогда гляньте в сторону IoTivity, у них довольно похожий с вашим подход, если я правильно понял.
6lowpan работают поверх 802.15.4 и поверх BT. А главное, что это просто IPv6. Поэтому это универсальная прослойка между ,, странными'' сетками. Т.е. поверх других физических интерфейсов не обязательно прокидывать именно 6lowpan. Достаточно прокинуть просто IPv6.
POSIX для Cortex M3 уже есть: NuttX
Занимаюсь подобными системами.
Начал «рисовать» сайт о своих продуктах ( opensource ): open-plc.com
Может быть есть смысл в сотрудничестве…
Занимаюсь подобными системами.
Начал «рисовать» сайт о своих продуктах ( opensource ): open-plc.com
Может быть есть смысл в сотрудничестве…
Либо я плохо прочитал статью, либо вы её не доконца проработали, либо у вас весьма туманное будущее.
1) Вы ориентируетесь на коммерческую направленность и хотите выступать технологическим провайдером для реализации технологии mesh, это неплохое решение для B2B engineering подрядов, жить в этом ключе вы сможете.
2) Вы зачем то «выпускаете» linux опенсорс версию на полноценной малине. Для реального применения в своих разработках людям опресненного решения нужен именно мк с вашей технологией, а не дорогая и энергозатратная малина. Вы что пытаетесь создать целый IoT «бассейн» на опенсорсном решении, а потом плавно продавать им свой коммерческий мк когда они вырастут из pet проектов в то, что может делать бизнес (или стартапить) и платить деньги? А у вас силёнок хватит? Этож получается практически EEE а таким может позволить себе заниматься (и успешно заниматься) некрософт скажем.
3) Вы правда хотите создать IoT «бассейн»? Эта статья выглядит одним из начальных шагов. У вас нет ресурсов. Я посетил ваш сайт (могли бы кстати не просто купить шаблон и залить туда текст, а хоть немного над ним поработать, вы на нём и свою команду разместили. Вы судя по всему либо студенты, либо вчерашние студенты. Вы стартап, откуда вам взять ресурсы на это дело? Вы должны противостоять огромному количеству больших компаний которые уже давно в этом направлении работают.
4) Вы говорите что все текущие решения для IoT не годятся. Долой их на свалку истории! «Покупайте» наше! Три ваших пункта в разделе <Кто виноват> абсолютно надуманы. Решения на мобильных сетях для IoT это очень маленький процент от всех кейсов.
5)Главный пункт вашей претензии к современным MESH решениям — что сложно подключить более 100 абонентов. Это не совсем так, для ZigBee вы частично правы, но в ZigBee и не требуется больше, ведь это домашняя и производственная автоматизация. Многие реализации 6lowpan позволяют иметь в сети более 1000 активных нод.
6) Вы делаете свою логическую MESH которая это «решает», а ресурсы то етсь? У вас что то заработало, но вы в начале пути.
Ещё мне не очень понятно на кого ориентированна статья. Для тех кто разбирается в вопросе в ней слишком много воды и прописных истин. Для тех кто не разбирается (а судя по статье она ориентированна на них) нет коммерческого интереса во все IoT теме.
В общем в любом случае я желаю вам творческих успехов. А я запасаюсь покорном и буду за вами приглядывать (конечно если вы будете притворствовать на хабре).
1) Вы ориентируетесь на коммерческую направленность и хотите выступать технологическим провайдером для реализации технологии mesh, это неплохое решение для B2B engineering подрядов, жить в этом ключе вы сможете.
2) Вы зачем то «выпускаете» linux опенсорс версию на полноценной малине. Для реального применения в своих разработках людям опресненного решения нужен именно мк с вашей технологией, а не дорогая и энергозатратная малина. Вы что пытаетесь создать целый IoT «бассейн» на опенсорсном решении, а потом плавно продавать им свой коммерческий мк когда они вырастут из pet проектов в то, что может делать бизнес (или стартапить) и платить деньги? А у вас силёнок хватит? Этож получается практически EEE а таким может позволить себе заниматься (и успешно заниматься) некрософт скажем.
3) Вы правда хотите создать IoT «бассейн»? Эта статья выглядит одним из начальных шагов. У вас нет ресурсов. Я посетил ваш сайт (могли бы кстати не просто купить шаблон и залить туда текст, а хоть немного над ним поработать, вы на нём и свою команду разместили. Вы судя по всему либо студенты, либо вчерашние студенты. Вы стартап, откуда вам взять ресурсы на это дело? Вы должны противостоять огромному количеству больших компаний которые уже давно в этом направлении работают.
4) Вы говорите что все текущие решения для IoT не годятся. Долой их на свалку истории! «Покупайте» наше! Три ваших пункта в разделе <Кто виноват> абсолютно надуманы. Решения на мобильных сетях для IoT это очень маленький процент от всех кейсов.
5)Главный пункт вашей претензии к современным MESH решениям — что сложно подключить более 100 абонентов. Это не совсем так, для ZigBee вы частично правы, но в ZigBee и не требуется больше, ведь это домашняя и производственная автоматизация. Многие реализации 6lowpan позволяют иметь в сети более 1000 активных нод.
6) Вы делаете свою логическую MESH которая это «решает», а ресурсы то етсь? У вас что то заработало, но вы в начале пути.
Ещё мне не очень понятно на кого ориентированна статья. Для тех кто разбирается в вопросе в ней слишком много воды и прописных истин. Для тех кто не разбирается (а судя по статье она ориентированна на них) нет коммерческого интереса во все IoT теме.
В общем в любом случае я желаю вам творческих успехов. А я запасаюсь покорном и буду за вами приглядывать (конечно если вы будете притворствовать на хабре).
Добрый день
1. Зачем мы выпускаем версию для «полноценного» linux на «полноценной» малине? Достаточно универсальная платформа, много скучающих программистов, гиков.
Мы бы хотели, чтобы в iot появлялось что-нибудь умнее лампочек и камер, а для этого, как нам кажется, нужны программисты, которые обычно не работают непосредственно с устройствами.
2. Что если кто-то сделает на открытой версии хороший продукт? Так это же будет замечательно, let it be, как нам кажется.
3. Мы начали работать с того, что нам не понравились Zigbee и 2g/3g. Оказалось, что потребность в новых решениях значительно больше и не ограничивается заменой плохого ZigBee и дорогого 2g/3g
1. Зачем мы выпускаем версию для «полноценного» linux на «полноценной» малине? Достаточно универсальная платформа, много скучающих программистов, гиков.
Мы бы хотели, чтобы в iot появлялось что-нибудь умнее лампочек и камер, а для этого, как нам кажется, нужны программисты, которые обычно не работают непосредственно с устройствами.
2. Что если кто-то сделает на открытой версии хороший продукт? Так это же будет замечательно, let it be, как нам кажется.
3. Мы начали работать с того, что нам не понравились Zigbee и 2g/3g. Оказалось, что потребность в новых решениях значительно больше и не ограничивается заменой плохого ZigBee и дорогого 2g/3g
1. Зачем мы выпускаем версию для «полноценного» linux на «полноценной» малине? Достаточно универсальная платформа, много скучающих программистов, гиков.
Мы бы хотели, чтобы в iot появлялось что-нибудь умнее лампочек и камер, а для этого, как нам кажется, нужны программисты, которые обычно не работают непосредственно с устройствами.
Это просто замечательное стремление. Но я ещё раз повторюсь |версия для «полноценного» linux на «полноценной» малине| подходит для pet проектов и то очень, очень ограничено. Если вы действительно хотите принести немного «доброты» в этот мир задаром, а не подсаживать всех на свою «платформу» — то открывайте проект на мк. Но вы не можете это сделать, т.к. потеряете основной продукт на котором вы зарабатываете, а зарабатывать деньги открывая продукт и работая интегратором и саппортом как большие компании вы тоже не можете, да и пока продукта готового у вас толком нет.
много скучающих программистов, гиков
Это я как понимаю ваша цель. Глупая цель, если это правда. Ну во первых скучающих программистов я ещё не видел, да и веселить их надо по другому. Вам не развлекать программистов надо, а делать коммерческий продукт и его продавать. Опенсорс не может быть прикрытием для этого. Только больные люди опенсорсят за так (да они есть и я их уважаю). В любом случае это либо работа в портфолио, либо открытасть ради развития и сборки багов и поддержки, либо как я и говорил делать открытый продукт и зарабатывать потом на наладке сопровождении. Моделей много, суть одна некая выгода. Не стоит маскироваться под чистые помыслы, а на самом деле пытаться сделать на этом площадку, рынок и влияние. В вашу безгрешность я не верю.
Да и зачем вам гики и программисты? Они привередливы и не платят. Вы не сделаете здесь денег, как минимум потому что вам не хватит ресурсов создать сообщество. Да и техническая проблема которую вы сейчас решаете очень узка, нужна не всем, и по большей части надуманна.
2Что если кто-то сделает на открытой версии хороший продукт? Так это же будет замечательно, let it be, как нам кажется.
Конечно именно поэтому, если это правда, я искренне желал вам удачи в прошлом коменте и желаю и сейчас.
3. Мы начали работать с того, что нам не понравились Zigbee и 2g/3g. Оказалось, что потребность в новых решениях значительно больше и не ограничивается заменой плохого ZigBee и дорогого 2g/3g
1) Эмм, как я понимаю вы ни чего другого не попробовали.
2) Вам Zigbee и 2g/3g не понравилось на вашей задаче.
3) Вы сделали вывод что все пути и технологии ошибочны
4) И теперь вы готовы сделать проект — техно мессия для IoT
5) и решить все проблемы
6) ???
7) Profit!
В общем и ещё раз, желаю вам успехов, грызите этот гранит. А я тем временем запасусь ещё ведёрком попкорна и буду ждать.
Но вы не можете это сделать, т.к. потеряете основной продукт на котором вы зарабатываете, а зарабатывать деньги открывая продукт и работая интегратором и саппортом как большие компании вы тоже не можете, да и пока продукта готового у вас толком нет.
Демагогия.
а) Вы не располагаете достаточной информацией ни о продукте, ни о степени его готовности.
б) Мы разрабатываем инструмент, c его помощью можно создавать продукт для конечного потребителя.
в) Это b2b решение. Если вы желаете поговорить про b, прошу в ЛС — мы рады помочь в решении ваших сетевых проблем.
Не стоит маскироваться под чистые помыслы, а на самом деле пытаться сделать на этом площадку, рынок и влияние. В вашу безгрешность я не верю.
Потрудитесь объяснить причем тут безгрешность?
Да и техническая проблема которую вы сейчас решаете очень узка, нужна не всем, и по большей части надуманна.
Вы в самом деле не понимаете? Погуглите про ботнет Mirai, такая очень узкая проблемка. Еще десяток таких надуманных ботнетов и будем дружно хоронить Интернет.
Вам Zigbee и 2g/3g не понравилось на вашей задаче
Назовете сходу стандарт который:
а) Не привязан к интерфейсу (частоте, модуляции, среде передачи)
б) Является полным стеком представленным на всех уровнях и реализующий функционал OSI, либо заменяющий ее.
в) Имеет поддержку хотя-бы пары RTOS и Linux.
Вы веткой ошиблись, ну да ладно.
Бред. Недаром я говорил про надуманные проблемы. Ботнет Mirai составлен большей частью не из IoT устройств, их правда приписывают к IoT но они таковыми не являются. Более того из википедии:
«Ботнет Mirai стал возможным благодаря реализации уязвимости, которая заключалась в использовании одинакового, неизменного, установленного производителем пароля для доступа к учетной записи администратора на «умных» устройствах»
Никакой проблемой в существующих IoT это не вызвано. Это банальная глупость производителя. Вы всё таки решили поиграть в техномиссию надуманных проблем?
Первый пункт потребовался лично вам на вашей задаче. И вы захотели странного и подумали какую крутую штуку вы изобрели. Сейчас это проблема согласоваения разных сетей решается и будет решаться за счёт бриджов прикладного уровня между сетями (есть ещё сетевые но там возможностей мало).
Отвечаю сразу на 3 пункта — IPv6, вы можете гнать его по любому интерфейсу, «тунелировать» в СAN, Zigbee и т.д… И самое главное у него есть отличная реализация в MESH — 6lowpan.
а) Конечно не располагаю, я оперирую текущей скудной информацией из вашей статьи и сайта. И конечно я могу ошибаться в.ч. по причине не виденьем полный картины вашей деятельности. Но мне достаточно и этого. Знания вопроса и логика компенсируют недостающую информацию.
б) Если вы про ваше решение на малине. То инструмент плох. Он дорог, габаритен, энергозатратен, не может долго автономно работать, имеет полноценную ОС и вычислительные возможности, что оверхед для задач на это решение возложенных.
Ещё раз открывайте «платформу» на мк. Это будет достойный инструмент для конечного потребителя.
в)
Вот вы и прокололись. Если это b2b решения зачем преподносить его под соусом опенсорса? Развивайте и продавайте ваш продукт, вы не на то силы тратите, выше в коментах я уже писал об этом.
Да и техническая проблема которую вы сейчас решаете очень узка, нужна не всем, и по большей части надуманна.Вы в самом деле не понимаете? Погуглите про ботнет Mirai, такая очень узкая проблемка. Еще десяток таких надуманных ботнетов и будем дружно хоронить Интернет.
Бред. Недаром я говорил про надуманные проблемы. Ботнет Mirai составлен большей частью не из IoT устройств, их правда приписывают к IoT но они таковыми не являются. Более того из википедии:
«Ботнет Mirai стал возможным благодаря реализации уязвимости, которая заключалась в использовании одинакового, неизменного, установленного производителем пароля для доступа к учетной записи администратора на «умных» устройствах»
Никакой проблемой в существующих IoT это не вызвано. Это банальная глупость производителя. Вы всё таки решили поиграть в техномиссию надуманных проблем?
Вам Zigbee и 2g/3g не понравилось на вашей задаче
Назовете сходу стандарт который:
а) Не привязан к интерфейсу (частоте, модуляции, среде передачи)
б) Является полным стеком представленным на всех уровнях и реализующий функционал OSI, либо заменяющий ее.
в) Имеет поддержку хотя-бы пары RTOS и Linux.
Первый пункт потребовался лично вам на вашей задаче. И вы захотели странного и подумали какую крутую штуку вы изобрели. Сейчас это проблема согласоваения разных сетей решается и будет решаться за счёт бриджов прикладного уровня между сетями (есть ещё сетевые но там возможностей мало).
Отвечаю сразу на 3 пункта — IPv6, вы можете гнать его по любому интерфейсу, «тунелировать» в СAN, Zigbee и т.д… И самое главное у него есть отличная реализация в MESH — 6lowpan.
Но вы не можете это сделать, т.к. потеряете основной продукт на котором вы зарабатываете, а зарабатывать деньги открывая продукт и работая интегратором и саппортом как большие компании вы тоже не можете, да и пока продукта готового у вас толком нет.Демагогия.
а) Вы не располагаете достаточной информацией ни о продукте, ни о степени его готовности.
б) Мы разрабатываем инструмент, c его помощью можно создавать продукт для конечного потребителя.
в) Это b2b решение. Если вы желаете поговорить про b, прошу в ЛС — мы рады помочь в решении ваших сетевых проблем.
а) Конечно не располагаю, я оперирую текущей скудной информацией из вашей статьи и сайта. И конечно я могу ошибаться в.ч. по причине не виденьем полный картины вашей деятельности. Но мне достаточно и этого. Знания вопроса и логика компенсируют недостающую информацию.
б) Если вы про ваше решение на малине. То инструмент плох. Он дорог, габаритен, энергозатратен, не может долго автономно работать, имеет полноценную ОС и вычислительные возможности, что оверхед для задач на это решение возложенных.
Ещё раз открывайте «платформу» на мк. Это будет достойный инструмент для конечного потребителя.
в)
Это b2b решение
Вот вы и прокололись. Если это b2b решения зачем преподносить его под соусом опенсорса? Развивайте и продавайте ваш продукт, вы не на то силы тратите, выше в коментах я уже писал об этом.
Никакой проблемой в существующих IoT это не вызвано.
Вы в корне неправильно понимаете суть проблемы в примере с Mirai. Подсказка — она не в уязвимости самих устройств (хотя, это тоже проблема, но совсем другая).
Если вы про ваше решение на малине
Нет. Это не является продуктом, это демонстрационный прототип о чем и было сказано в статье.
Отвечаю сразу на 3 пункта — IPv6, вы можете гнать его по любому интерфейсу, «тунелировать» в СAN, Zigbee и т.д… И самое главное у него есть отличная реализация в MESH — 6lowpan.
Спасибо. Предлагаю на этом закончить.
Вы в корне неправильно понимаете суть проблемы в примере с Mirai. Подсказка — она не в уязвимости самих устройств (хотя, это тоже проблема, но совсем другая).
Так расскажите мне суть проблемы мессия. Как я понял вы намекаете на то что проблема в том, что любая камера (которая ещё раз подчёркиваю не является IoT) в Mirai может вещать куда угодно в интернет, ну и что??? Это не проблема IoT его тут нет, это не проблема MESH. И в статью ваше объяснение бы не плохо добавить (или в следующую она же будет да?), ото всё что там есть — что текущие решения не годятся. Впрочем я жду вашего «релиза» чтобы посмотреть как же у вас там революционно будет обеспечиваться «безопасность» и нейросеть тоже жду.
Нет. Это не является продуктом, это демонстрационный прототип о чем и было сказано в статье.
Ок, жду продукт.
Отвечаю сразу на 3 пункта — IPv6, вы можете гнать его по любому интерфейсу, «тунелировать» в СAN, Zigbee и т.д… И самое главное у него есть отличная реализация в MESH — 6lowpan.Спасибо. Предлагаю на этом закончить.
Очень зря предлагаете, расскажите почему вы не согласны с моим ответом, что в нём неверного. Вы просили удовлетворить три ваших пункта я удовлетворил, уточните вопрос если он не полон, переформулируйте, или просто без вопроса скажите что пытались.
Я как ваш потенциальный клиент (без шуток) жду ответ. Впрочем как и другие потенциальные клиенты которые этот комент прочитают.
Sign up to leave a comment.
Стек протоколов для Интернета вещей