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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот и я о том, что без (центрального) сервера никуда.
Может я чего-то не понял, но таких вот REST клаудов уже полно и с огромными инвестициями, в чем преимущество DeviceHive?
Возможность выбора — всегда хорошо. 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 в коммерческих проектах. Более того, на примере этой прошивки мы предлагаем комплексное решения для реального железного воплощения интернет вещей, а не просто абстрагированный от реального оборудования клауд.
EJB там остался большей частью исторически, т. к. был нужен на одном из этапов разработки. Уже есть версия на spring-boot без EJB, и DeviceHive 2.0.2 будет без него по умолчанию.
что у него с безопасностью? очередная дырявая поделка или продумали?
Аутентификация на сервере происходит при помощи DeviceId и DeciveKey, т. е. имя пользователя/пароль. Устройство фактический является пользователем в системе DeviceHive. В DeviceHive имеется продуманная модель безопасности, которая позволяет ограничивать доступ к сетям, устройствам, вызовам API, фильтровать по IP/доменам, ограничивать количество попыток входа в систему, блокирование попыток подбора пароля, SSL/TLS-подключения.
Это все прекрасно, но частотный диапазон WiFi в обычном многоквартирном доме засран, дальше некуда… Обеспечить надежную работу системы в таких условиях будет реальной проблемой…
Здравствуйте! Может быть интегрируем DeviceHive в MajorDoMo? Почему бы не предоставить ещё одну опцию для пользователей по построению домашней сети сенсоров.
А возможна ли работа ESP8266 с обычными бескорпусными видеокамерами, или не хватит производительности для обработки H264 потока? И если нет, то к какой плате можно присматриваться для решения этой задачи?
У ESP8266 нет интерфейса для параллельной камеры, так же нет USB, так же нет поддержки USB-v4l2 стека, как нет и ядра Linux.
Из максимально дешёвых можно купить эту плату. А вот эта идёт прямо с камерой в комплекте. Лично я сам использую эту плату ( у неё есть хорошая коробочка и необходимый и достаточный набор интерфейсов для задач, которые приходиться решать на практике).
Спасибо за помощь! A20-SOM-EVB с камерой, конечно, удобно. Единственно, моя задача больше в приоритет выводит стоимость и энергопотребление. Плата RT5350F за 15 евро мне нравится. Вот на Ваш взгляд, ее будет достаточно для реализации автономной видеокамеры с передачей потока по Wi-Fi?
Зависит от формата потока (MJPEG, RTSP (h.264), YUYV) и WiFi и самой USB камеры. Любое их перечисленных условий может снизить скорость с 30 FPS до 1 FPS.

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

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

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