IoT за копейки, или Что может DeviceHive

    В современном мире «интернет вещей» (IoT) стремительно набирает популярность. Он в будущем поможет человечеству автоматизировать многие аспекты жизни, упростить рутинные операции, да и просто сделать жизнь комфортнее и приятнее. Современная элементная база только способствует этому. Еще несколько лет назад задача управления устройством из сети порождала необходимость использовать высокопроизводительные процессоры, что увеличивало стоимость конечного исполнительного устройства в разы. Сейчас же есть возможность построить простые и эффективные IoT-решения за копейки.

    Сделать свой дом поистине «умным» можно и без использования модных Raspberry Pi или Arduino. Большинство IoT-задач сводится к подключению типовых датчиков и исполнительных механизмов со стандартными интерфейсами: I2C, SPI, UART. А иногда даже с элементарным аналоговым выводом, с которого нужно считать наличие напряжения или подать его, или просто замкнуть.



    Вот россыпь датчиков — примерно $ 20 за все. Продаются на куче онлайн-площадок (Aliexpress, Ebay и т. п).



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



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

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

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

    Большинство разработчиков предпочтет использовать широко распиаренные Raspberry Pi или Arduino — это все равно что стрелять из пушки по воробьям. Разработчиков привлекает простота написания приложения для данных платформ и большое сообщество. При этом такие задачи можно решить, используя микросхемы стоимостью по два доллара ($ 2,5 в виде модуля на большинстве китайских торговых площадок, включая доставку) и при этом получить все преимущества и гибкость разработки на вашем любимом языке. В итоге получится полноценное IoT-устройство, которое является частью сети, позволяя легко масштабировать и изменять систему. Подключаться к сети оно будет при помощи обыкновенного Wi-Fi, который чаще всего уже есть.

    При такой стоимости во многих случаях будет дешевле установить такой модуль, чем прокладывать кабель (стоимость меди + прокладки). Если бы все производители договорились бы устанавливать подобные интерфейсы в бытовые приборы (например, в вышеописанную кофеварку), стоимость производства большинства устройств увеличилась бы на копейки, но при этом «умный дом» был бы действительно умным и недорогим.

    Исходя из вышеописанного, очень выгодно смотрится микроконтроллер ESP8266 со встроеным Wi-Fi-модулем. Однако его программирование может потребовать недюжинных усилий и умений — не зря же его часто подключают к другим платформам для получения Wi-Fi-соединения через UART, используя стандартную прошивку от произоводителя. Да и изобретать велосипед — как-то странно…

    DeviceHive

    Мы предлагаем использовать нашу платформу с открытым исходным кодом DeviceHive и микросхему ESP8266 c нашей прошивкой, реализующей протокол DeviceHive на этом SoC. Вам останется лишь подключить устройство к модулю и общаться с серверов DeviceHive по HTTP или через WebSocket в среде, в которой вы привыкли.

    Мы предоставляем свой код под лицензией MIT — серверной части и всего клиентского ПО. Сервер можно легко развернуть и облачном сервисе, и в локальной сети. Чтобы просто поиграть и попробовать DeviceHive в действии, можно воспользоваться бесплатным плейграундом.

    Общение с прошивкой для ESP8266 сводится к трем простым действиям:
    • послать команду на устройство для осуществления какого-либо действия (активирование выводов микросхемы, запись данных в интерфейс, включение «подтяжки» для входных выводов микросхемы, запрос состояния выводов, уведомление сервера об изменении уровня на выводах);
    • спросить сервер о результате выполнения команды;
    • начать «поллить» уведомления, на которые подписались при помощи команд.


    Рассмотрим, как послать команду по HTTP, на примере JavaScript:

    function send(command, r, g, b) {
          var xmlhttp = new XMLHttpRequest();  
          xmlhttp.open('POST', 'http://server.example.com/api/device/device-uuid/command', true);
          xmlhttp.setRequestHeader("Authorization", "Basic " + btoa("user:password"));
          xmlhttp.setRequestHeader("Content-type", "application/json;charset=UTF-8");
          var myjson = {};
          myjson["command"] = command;
          myjson["parameters"] = {};
          myjson["parameters"][12] = r;
          myjson["parameters"][13] = b;
          myjson["parameters"][14] = g;
          xmlhttp.send(JSON.stringify(myjson));
         }
    


    Затем достаточно позвать эту функцию, например, send('gpio/write', 1, 0, 0), указав команду и параметры. В данном случае команда “gpio/set” установит логическую единицу на выводе GPIO12 и логический ноль на выводах GPIO13 и GPIO14, после чего подключенное устройство выполнит что-то. Просто, не правда ли?

    Написание HTTP-запроса, задача, решенная для любого языка программирования, т.е. разработчик может реализовывать свое клиентское приложение в любой среде разработки, на любой платформе, и при этом управлять настоящим IoT-устройством.

    В планах реализовать:
    • SPI;
    • I2C;
    • UART;
    • ADC (аналоговый вход);
    • 1-wire-интерфейс для DS18B20 и DHT11;
    • PWM (ШИМ, широтно-импульсная модуляция).


    Пока есть только демо, но в ближайшее время появится версия с открытым исходным кодом, доступная всем для скачивания. Следите за обновлениями. С первым релизом подготовим еще одну статью с подробным видео, рассказывающуя, как завести плейграунд DeviceHive, как прошить и запустить модуль с ESP8266, подключив простейшие дискретные устройства. И напишем простую веб-страничку, чтобы ими управлять.

    Автор: Николай Хабаров, Senior Embedded Developer
    DataArt 85,17
    Технологический консалтинг и разработка ПО
    Поделиться публикацией

    Вакансии компании DataArt

    Комментарии 69
    • 0
      Отличное решение — когда-то разработчик, желающий вывести в Интернет свое устройство (если на борту был не *nix, конечно) был вынужден применять WiFi <-> UART или WiFi <-> SPI конвертеры по $30 за штуку (или как вариант — Zigbee за столько же и RaspPi как мост Zigbee — WiFi), плюс реализовывать кастомную логику обмена на серверной и клиентских (а на клиенте с ресурсами всегда напряг) сторонах.

      С DeviceHive же для простых применений (типа открыть-закрыть жалюзи в комнате, включить-выключить кран, измерить температуру/освещенность), как я понимаю, даже не нужен отдельный МК — так как код выполняется в самом ESP8266, и если хватает выводов на простые функции, то за пару долларов реализуется полноценный IoT-enabled DIY-контроллер — что-то наподобие electricimp, только не требующий SD-сокета и технологической платы.

      BTW, а как решается вопрос конфигурации ESP8266 'с нуля' для подсоединения к WiFi-сети?
      • +1
        Совершено верно: чтобы реализовать простейшее DIY-устройство, ничего, кроме esp8266, не нужно. Конфигурирование Wi-Fi сети и настроек сервера DeviceHive будет происходить через терминал по UART. В любом случае, в начале нужно прошить esp8266, а это делается через UART, т. е. можно, не отключая переходник от модуля, залить прошивку и сразу настроить её.
        • +1
          Эх, еще бы устранить слово 'переходник' и железо, которое за ним стоит — иначе получается, что если WiFi-роутер поменял SSID или пароль, нужно доставать из шкафа USB <-> RS232 девайс плюс RS232 <-> UART-3.3 конвертер, все это соединять, вынимать все ESP8266 из всех углов дома, и перепрошивать. Неудобно.

          Вернее, так: начальную конфигурацию конечно делать неудобно, а вот реконфигурацию можно наверное сделать и средствами самого DeviceHive, предусмотрев соответствующую команду
          • +2
            Прошивка сейчас находится в разработке, и подобную команду для удаленной смены конфигурации, скорее всего, добавим на одном из этапов разработки. Но в любом случае стоимость USB->UART-переходника на Aliexpress, Ebay — от $1 с доставкой, соединять USB->RS232->UART нет никакого смысла.
            • +1
              Но «вынимать все ESP8266 из всех углов дома» все равно придется ведь…
              • 0
                На ESP8266-EVB c этой прошивкой вопрос переконфигурации решается через удалённый WEB интерфейс и\или использованием аппаратной кнопки, которая меняет режим работы AP, ST, AP+ST.
                • 0
                  Только если без вашего ведома неожиданно поменяли параметры Wi-Fi-сети. И то можно с ноутбуком пробежаться до каждого устройства, подключив три провода/разъем, прописать новые параметры.
                  А во всех остальных случая, можно дать команду на использование новой Wi-Fi-сети удалено, затем поменять параметры роутера, и все девайсы прицепятся к новой сети.
            • +1
              В примерах SDK есть схема, когда несконфигурированный модуль становится AP. Подсоединяетесь к этой АП, конфигурите вайфай, ребутитесь, модуль в режиме клиента и цепляется у сети. Наменого удобнее, чем через терминал…
          • +1
            Кстати, а что у DeviceHive с поддержкой спящих режимов в девайсах? Как я понимаю, в активном режиме потребление ESP8266 — порядка десятков или даже сотен миллиампер, что делает сомнительным создание сколько-нибудь автономных устройств на нем.

            Вот здесь на хабре описаны эксперименты с введением модуля в спящий режим — для многих применений его поддержка — единственный ключ к автономности
            • +1
              У любого чипа, использующего Wi-Fi, энергопотребление всегда довольно велико. Однако т. к. у DeviceHive есть удаленный сервер, который сохраняет все команды, появляется возможность уводить esp8266 в спящий режим и пробуждать спустя какое-то время для запроса сервера на предмет команд, которые могли прийти, когда чип спал. Поэтому, исходя из логики реализуемого устройства (можно ли уводить чип в спящий режим на какое-то время) в некоторых случаях будет возможно получить довольно низкое энергопотребление.
              • +1
                То, что в DeviceHive это продумано — хорошо. Респект разработчикам. В голову сразу приходят разные варианты использования — например, ядро просыпается раз в 5 минут, измеряет температуру объекта, если дельта-T меньше некоего порога, устройство засыпает снова. Если больше — активизирует радиомодуль, устанавливает WiFi-соединение, отсылает данные в DeviceHive.
                Или так — DeviceHive имеет команду, указывающую устройству период активизации — таким способом можно динамически конфигурировать оперативность отклика того или иного устройства прямо с сервера. Вот здесь был пост о питании ESP8266 от солнечных батарей — там может сильно пригодиться.

                И последняя идея — для всех мобильных устройств и особенно wearables контроль энергопотребления — первоочередная задача, так как в сегодняшнем КМОП-мире объем вычислений — практически линейная функция от запасенной в батарее энергии. Почему бы не ввести в «ядро» DeviceHive функции управления питанием, как это сделано в мобильных операционных системах — тогда подобные базовые вещи были бы реализованы из коробки универсальным образом, и это открыло бы дорогу к автономным применениям IoT — то есть к тому, что сейчас является последним камнем преткновения широкому распространению IoT-enabled систем? Еще один камень — 1-dollar IoT chip — практически уже преодолен, в частности, как раз средствами ESP8266, и не в последнюю очередь, как я понимаю, усилиями DeviceHive
            • +1
              Почти все то что тут описано уже реализовано в этой прошивке(+возможность обновления по воздуху). Единственное прошивка там закрытая, но текущий функционал просто огромен.
              • 0
                Там ведь даже спящий режим за деньги, не смотря на то, что это вызов всего одной функции на сях. Да и большая часть функционала той прошивки доступна на github в виде различных проектов и примеров, стоит лишь собрать их воедино. Для этого конечно потребуется знание и умение программировать.
                • 0
                  Спящий режим очень проблемная штука, кроме самого контролера надо еще отключать питание датчиков, у разных датчиков разное время выхода на рабочий режим, в итоге очень много нюансов и не достаточно отправлять в сон только сам контролер. Ну стоимость которую просит автор за доп функционал достаточно скромная!
                  • +1
                    Да, 100 рублей за каждый модуль это совсем не много. Но ведь и все нюансы с датчиками разобраны ещё до появления на рынке esp8266.
              • 0
                У ESP8266 есть недостаток — слабый сигнал. Дальность 20 метров со стенами. Получается в каждое удалённое помещение ставить отдельный роутер? Поэтому переходят постепенно на другие платформы. А ESP8266 — для экстремально не дорогих решений.
                • 0
                  esp долбит на километры
                  www.youtube.com/watch?v=7BYdZ_24yg0
                  • 0
                    Это в идеальных условиях на открытом воздухе около 300 метров (без других WiFi сигналов на том же диапазоне) и со специальными антеннами и без стен и зелени. Я не знаю как они измеряли расстояние в первом фрагменте, но двигались они по окружности дороги.

                    В реальных условиях, когда вокруг десятки сетей и в помещении ещё 2 сегмента WiFi на роутерах Motorola_AP5131 плюс соседние сети плюс коммерческие, реальная дальность 25 метров и 3 бетонных стены включительно и масса металических шкафов склада.
                    • 0
                      Ну там же в конце данные — с внешней антенной и с pcb и сравнение с роутером ТП-линк. 3 с лишним км на своей антенне.
                      Ой, тупанул. 400м с обычным роутером и 3,6 км с тарелкой.
                      • 0
                        Да там они использовали отражатель с приличной площадью (вероятно вы его тарелкой называете, а я специальной антенной).
                        У полосковых и сегментных (спиральных) антеннах для самого ESP8266 так же есть специфика в диаграммах направленности и пр.

                        Исходники частного решения систем уравнений для этих антен на Python можно посмотреть тут.
                  • 0
                    Но ведь esp8266 может одновременно работать в режиме клиента и точки доступа, а значит ничего не мешает сделать mesh и обойтись либо вообще роутера (зачем умному дому интернет?), либо с одним роутером, через который вся сеть будет общаться с интернетом или локальным контроллером.
                    • +1
                      Да можно сделать. У Souliss есть такая попытка. Вы попробуйте сделайте сами и желательно сразу передайте код в OS. Думаю это может занять от 1 месяца (в случае использования частей готового кода) до 1 года. То есть около $25 000. Видимо поэтому ещё не сделали. Или просто мне не известны такие решения. IMHO
                      • 0
                        Наверняка ещё не сделали лишь потому, что хотя китайцы и написали единичку в мажорной версии своего SDK, но на самом деле «ноль пишем, один в уме». Боятся чего то, не выкладывают сорцы для своих обёрток и костылей, от которых больше пользы или вреда, не понятно. Пока что у меня лично не появилось необходимости в дополнительных точках, одного роутера, висящего посередине деревянного дома вполне хватило чтобы не только покрыть его полностью, но и иметь стабильную связь на расстоянии метров 50 от него с модулем «01» (в метрах 100 связь по прежнему есть, но esp периодически самопроизвольно ребутается). Но так как это занятие лишь хобби и никакого дохода не приносит, то занимаюсь я им в свободное от работы время и по возможности делюсь результатами с общественностью.
                    • 0
                      Дальность приёма — понятие растяжимое, зависящее от множества факторов. Но прелесть использования Wi-Fi в том, что он уже очень часто есть готовый. Наверняка у 99.9 % читателей он есть дома. Для удалённых помещений, будь то Wi-Fi или любой другой способ связи, всегда будут возникать трудности с прокладкой проводов/установкой шлюза, причем роутер Wi-Fi — одно из самых недорогих решений.
                    • 0
                      Все эти умные дома какие-то бестолковые, сводятся к включении кофеварок, света, набора ванны и т.д. и т.п., хоть раз бы описали действительно интересную задачу, решаемую этим домом) хотя б в теории)
                    • 0
                      Собственно, чтоб далеко не ходить, вот эти наборы датчиков на Амазоне:

                      image image image image

                      От 20 долларов за набор
                      .
                      • 0
                        А если не сложно, можно сюда же ссылки на все остальное детали докидать? Для начала хотя бы набор для изготовления выключателя лампочки. Я так понимаю там ведь нужен сам чип + прошиватель (да простят меня гики, если что не так сказал). Тема на самом деле реально крутая и очень приятно что все начинает сводится к тому что вот тебе пару датчиков, вот тебе контроллер, просто вотки провода друг в друга и будет тебе моргающая лампочка.
                    • 0
                      Сделать свой дом поистине «умным» можно и без использования модных Raspberry Pi или Arduino.

                      Можно, но сложно. Для действительно «умного» дома нужна вычислительная мощность, а ее у esp8266 всеже маловато. Про «облако» конечно ясно, но мне например совсен не улыбается видеть управление моего жилища на чужих серверах в интернете. Ну или интернет упадет. Значит всеже нужен локальный сервер. Тут-то Raspberry и пригодится. Хотя я предпочитаю Cubietruck.
                      А совсем без центрального сервера (на одних напрямую связанных отдельных модулях) ничего особо умного, боюсь, не получится.

                      Или как например реализовать следующий функционал:

                      Дано: электронно управляемые наружные залюзи, сенсоры освещенности, температуры, датчики движения.
                      Задача: при высокой температуре и яркости солнца частично закрывать жалюзи для предотвращения перегрева помещений. Разумеется для всех окон отдельно. Для этого расчитывается положение и высота солнца и на основании этого вычисляется, насколько сильно солнце «заглядывает» в комнату. На основании датчиков движения в комнатах система пытается действовать максимально незаметно (в зависимости от выбранного пользователем режима). и т.д.
                      • 0
                        Можно просто к термостату c веб-интерфейсом на ESP8266 подключить управление жалюзями, датчики движения — всё через I2C. Сигнал от сенсоров освещённости, кстати, можно взять либо от наружных камер, либо вычислить на основе широты места и времени суток и прогноза погоды :-), либо сенсор освещённости встроен в датчик движения и сигнал можно взять из датчика.
                        • 0
                          Можно наверное, но ведь получится инвалидная коляска на костылях. В чем преимущество перед централизированным управлением?
                          Вычисления освещенности отметем сразу как совершенно негодные для данной цели. Тут нужны реальные данные. Вычисления (даже с учетом локальной погоды из интернета) я уже пробовал для определения времени закрытия залюзи на ночь. Даже для этого абсолютно не достаточно.

                          Здесь что получается? На каждое окно собственный веб-интерфейс? Да еще со своим полным комплектом датчиков? Вместо того, чтобы все данные (и веб-интерфейс) предоставлять центрально? Смысл-то где?

                          Освещенность от датчика движения кстати не годится. Это же освещенность в помещении, а нужна интенсивность наружнего солнечного излучения.

                          • 0
                            Веб интерфейс на ESP8266 много места не занимает. Там ещё API есть на POST запросах, поэтому отдельного комплекта сенсоров не надо, достаточно управлять с IP модуля видеокамеры (использовать в качестве сервера). Для видеокамер тоже есть прошивки. На юге жалюзи почти всегда закрыты, открывают часто только для проветривания утром и если нужно естественное освещение днём, то их просто приоткрывают до появления отверстий. То есть настройки зависят от владельца и сильно отличаются для каждого конкретного случая. Где то управление жалюзями окон спаренное по 2 окна, где то шина используется типа матрица. IMHO
                            • 0
                              Ну зачем костыльное решение, если можно нормальный сервер поставить?
                              • 0
                                У меня на камерах стоит 1 модуль A20. Говорят в 4 раза быстрее RPi, при той же цене. Но на камере за 17 евро то же можно запустить веб сервер :-)
                                • 0
                                  У меня тоще А20 (Cubietruck). Быстрее первого Pi намного, второй версии — пожалуй нет.
                                  • 0
                                    Согласен, только у меня OLinuXino. Очень порадовал настроенный rtps стрим сервер прямо в заводском имидже и возможность батареи подключать. Можно вместо блока питания сразу включить солнечную панель. Не одной заминки не с чем из драйверов, пока не было.
                                    • 0
                                      Тоже неплохой девайс. Жаль только, что производитель с памятью пожадничал.
                                      • 0
                                        Вроде всё в порядке с памятью. 1GB DDR3 RAM memory, 4GB NAND Flash, SD card.
                                        • 0
                                          А, ОК, у Лиме2 1GB. И цена приятная.
                                          При быстром поиске мне попалась первая версия с 512Кб. Этого мне было бы маловато.
                                          • 0
                                            Если кому интересно:
                                            Цена в Испании\Мурсии
                                            Цена при самовывозе из Испании\Мурсии — 50 евро вместе с корпусом который даёт возможность использовать устройство в индустриальном диапазоне температур.
                        • 0
                          А вот тут и начинаются прелести использования DeviceHive в качестве сервера. DeviceHive можно развернуть на любом сервере с помощью докера за считанные минуты — registry.hub.docker.com/u/devicehive/devicehive
                          При этом нет никакой необходимости в интернете. Иначе говоря, инфраструктура может находиться целиком внутри локальной сети.
                          Производить сколько-нибудь сложные вычисления на esp8266, разумеется, не стоит, т. к., например, в случае изменения алгоритма придется перепрограммировать каждую, а в случае сервера — все управление на нём. esp8266 — лишь прозрачный шлюз между электрическими сигналами и программой, а сервер — центр управления.
                          • 0
                            Я не пробовал использовать DeviceHive, не смогу оценить все плюсы решения. Просто для информации, например Souliss вообще не требует сервера. Все управляющие программы запускаются внутри Андроид приложения, включая веб-сервер с API интерфейсом. Так же предусмотрен обмен конфигурациями и самомаршрутизирующаяся меш сеть.
                            • 0
                              Просто для информации, например Souliss вообще не требует сервера. Все управляющие программы запускаются внутри Андроид приложения, включая веб-сервер с API интерфейсом.

                              Т.е. этот андроид нужно будет навечно прибить на стену (чем мы получим центральный сервер, только на основе Андроид).
                              В другом случае кому-нибудь придет в голову взять этот Андроид с собой из дому (алтернативно: уронить на пол, забыть зарядить, разбить о стену) и весь дом останется без автоматики.

                              Ненадежное какое-то это решение, непрофессиональное…
                              • 0
                                Можно задать вопрос в группе. Там есть несколько профессионалов. Основной управляющий модуль там — ардвино или ESP8266 а не Андроид. Вропчем с Андроида то же можно.
                                • 0
                                  Для моих целей, ардуино слишком (слишком-слишком) слаб. Да и ESP тоже…
                            • 0
                              А вот тут и начинаются прелести использования DeviceHive в качестве сервера.

                              Вот и я о том, что без (центрального) сервера никуда.
                          • –1
                            Может я чего-то не понял, но таких вот REST клаудов уже полно и с огромными инвестициями, в чем преимущество DeviceHive?
                            • 0
                              Возможность выбора — всегда хорошо. DeviceHive — на 100 % открытый. Все исходные коды сервера можно посмотреть, изучить, а, если хотите, и поправить под свои нужды. Лицензия MIT. DeviceHive признан мировыми лидерами: Microsoft, Canonical. Вот свежая статья на Forbes: www.forbes.com/sites/janakirammsv/2015/05/12/canonical-and-ge-announce-smart-fridge-powered-by-snappy-ubuntu-core
                              Множество частных компании используют DeviceHive в коммерческих проектах. Более того, на примере этой прошивки мы предлагаем комплексное решения для реального железного воплощения интернет вещей, а не просто абстрагированный от реального оборудования клауд.
                              • 0
                                Да я даже просмотрел Ваш код, зачем там EJB?
                                • 0
                                  EJB там остался большей частью исторически, т. к. был нужен на одном из этапов разработки. Уже есть версия на spring-boot без EJB, и DeviceHive 2.0.2 будет без него по умолчанию.
                            • 0
                              что у него с безопасностью? очередная дырявая поделка или продумали?
                              • 0
                                Аутентификация на сервере происходит при помощи DeviceId и DeciveKey, т. е. имя пользователя/пароль. Устройство фактический является пользователем в системе DeviceHive. В DeviceHive имеется продуманная модель безопасности, которая позволяет ограничивать доступ к сетям, устройствам, вызовам API, фильтровать по IP/доменам, ограничивать количество попыток входа в систему, блокирование попыток подбора пароля, SSL/TLS-подключения.
                              • 0
                                Это все прекрасно, но частотный диапазон WiFi в обычном многоквартирном доме засран, дальше некуда… Обеспечить надежную работу системы в таких условиях будет реальной проблемой…
                                • 0
                                  Здравствуйте! Может быть интегрируем DeviceHive в MajorDoMo? Почему бы не предоставить ещё одну опцию для пользователей по построению домашней сети сенсоров.
                                  • 0
                                    В личке пообщаемся.
                                  • 0
                                    А возможна ли работа ESP8266 с обычными бескорпусными видеокамерами, или не хватит производительности для обработки H264 потока? И если нет, то к какой плате можно присматриваться для решения этой задачи?
                                    • +1
                                      У ESP8266 нет интерфейса для параллельной камеры, так же нет USB, так же нет поддержки USB-v4l2 стека, как нет и ядра Linux.
                                      Из максимально дешёвых можно купить эту плату. А вот эта идёт прямо с камерой в комплекте. Лично я сам использую эту плату ( у неё есть хорошая коробочка и необходимый и достаточный набор интерфейсов для задач, которые приходиться решать на практике).
                                      • 0
                                        Спасибо за помощь! A20-SOM-EVB с камерой, конечно, удобно. Единственно, моя задача больше в приоритет выводит стоимость и энергопотребление. Плата RT5350F за 15 евро мне нравится. Вот на Ваш взгляд, ее будет достаточно для реализации автономной видеокамеры с передачей потока по Wi-Fi?
                                        • 0
                                          Зависит от формата потока (MJPEG, RTSP (h.264), YUYV) и WiFi и самой USB камеры. Любое их перечисленных условий может снизить скорость с 30 FPS до 1 FPS.

                                          Вот этой (которая появиться летом в продаже) или вот этой (которая вообще не известно когда появиться в продаже) вам хватит с гарантией.
                                          • 0
                                            Первая ссылка не работает. Сайт лег или ошиблись в написании?
                                            • 0
                                              Всё работает. Сделайте запрос «A33-OLinuXino Open Source Hardware Linux SBC with Quad Core Cortex-A7 ARM processor running at 1.5Ghz.» Скорее всего у вас сертификаты SSL не всех версий в браузере подключены (Просто как гипотеза, <шутка>я же не народный целитель чтоб по сообщению и нику диагностировать проблемы на вашем сегменте сети и у вашего устройства ;-) <конец шутки> ).
                                              • 0
                                                Ясно, спасибо. Нашел плату.
                                    • 0
                                      Подскажите, а есть устройства с GPIO на подобии ESP8266, но исспользуещие BLE вместо WiFi?

                                      Из-за высокого потребления электроэнергии ESP8266 не совсем идеальное решение. Другими словами ESP8266 будет всегда исспользоваться только там, куда можно подвести питание или куда можно установить относительно крупную батарею.

                                      И соответственно в продолжение предыдущей мысли, логично предположить, что эта проблема могла бы быть решена заменой WiFi на BLE.
                                      • +1
                                        Такие SoC существуют, их много, например, nrf51822 и cc2540. Теоретический подобные устройства могут существовать до года в режиме адвертайзинга при питании от батарейки типа CR2032. Однако эти устройства не способны самостоятельно выходить в интернет и подключаться к удаленному серверу. Для их работы с удаленным сервером нужно устанавливать специальный шлюз соединяющий BLE и удаленный сервер. Также работа с этими микросхемами потребует приобрести специальный программатор для загрузки прошивки в них. nrf51822, например, официально прошивается с помощью Segger J-Link который официально стоит от $ 60 за учебную версию и от $ 378 за полнофункциональную (существуют китайские контрафактные версии ~$ 20). Для микросхем серии ccXXXX нужен CC Debugger стоимость $ 49. Что согласитесь, может быть неприемлемо для DIY-устройств стоимостью $ 5.
                                      • 0
                                        Подскажите, для работы DeviceHive, доступ к интернету нужен всгда или только в момент конфигурирования?
                                        И можно ли исспользовать DeviceHive с домашними контроллерами умного дома?
                                        • +1
                                          Если сервер развернут локально, интернет вообще не нужен. Если сервер в интернете, да, нужен постоянно.
                                          Организовать работу с любыми сторонними контролерами возможно. Нужно либо научить контроллер использовать DeviceHive, или написать приложение, берущее данные с сервера DeviceHive и управляющее этим контроллером.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое