Сделать свой дом поистине «умным» можно и без использования модных 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
Комментарии (65)
gleb_l
16.06.2015 17:00+1Кстати, а что у DeviceHive с поддержкой спящих режимов в девайсах? Как я понимаю, в активном режиме потребление ESP8266 — порядка десятков или даже сотен миллиампер, что делает сомнительным создание сколько-нибудь автономных устройств на нем.
Вот здесь на хабре описаны эксперименты с введением модуля в спящий режим — для многих применений его поддержка — единственный ключ к автономности
DataArt Автор
16.06.2015 17:56+1У любого чипа, использующего Wi-Fi, энергопотребление всегда довольно велико. Однако т. к. у DeviceHive есть удаленный сервер, который сохраняет все команды, появляется возможность уводить esp8266 в спящий режим и пробуждать спустя какое-то время для запроса сервера на предмет команд, которые могли прийти, когда чип спал. Поэтому, исходя из логики реализуемого устройства (можно ли уводить чип в спящий режим на какое-то время) в некоторых случаях будет возможно получить довольно низкое энергопотребление.
gleb_l
16.06.2015 18:21+1То, что в DeviceHive это продумано — хорошо. Респект разработчикам. В голову сразу приходят разные варианты использования — например, ядро просыпается раз в 5 минут, измеряет температуру объекта, если дельта-T меньше некоего порога, устройство засыпает снова. Если больше — активизирует радиомодуль, устанавливает WiFi-соединение, отсылает данные в DeviceHive.
Или так — DeviceHive имеет команду, указывающую устройству период активизации — таким способом можно динамически конфигурировать оперативность отклика того или иного устройства прямо с сервера. Вот здесь был пост о питании ESP8266 от солнечных батарей — там может сильно пригодиться.
И последняя идея — для всех мобильных устройств и особенно wearables контроль энергопотребления — первоочередная задача, так как в сегодняшнем КМОП-мире объем вычислений — практически линейная функция от запасенной в батарее энергии. Почему бы не ввести в «ядро» DeviceHive функции управления питанием, как это сделано в мобильных операционных системах — тогда подобные базовые вещи были бы реализованы из коробки универсальным образом, и это открыло бы дорогу к автономным применениям IoT — то есть к тому, что сейчас является последним камнем преткновения широкому распространению IoT-enabled систем? Еще один камень — 1-dollar IoT chip — практически уже преодолен, в частности, как раз средствами ESP8266, и не в последнюю очередь, как я понимаю, усилиями DeviceHive
beho1der
16.06.2015 18:45+1Почти все то что тут описано уже реализовано в этой прошивке(+возможность обновления по воздуху). Единственное прошивка там закрытая, но текущий функционал просто огромен.
DarkByte
16.06.2015 19:00Там ведь даже спящий режим за деньги, не смотря на то, что это вызов всего одной функции на сях. Да и большая часть функционала той прошивки доступна на github в виде различных проектов и примеров, стоит лишь собрать их воедино. Для этого конечно потребуется знание и умение программировать.
beho1der
16.06.2015 22:09Спящий режим очень проблемная штука, кроме самого контролера надо еще отключать питание датчиков, у разных датчиков разное время выхода на рабочий режим, в итоге очень много нюансов и не достаточно отправлять в сон только сам контролер. Ну стоимость которую просит автор за доп функционал достаточно скромная!
DarkByte
16.06.2015 22:16+1Да, 100 рублей за каждый модуль это совсем не много. Но ведь и все нюансы с датчиками разобраны ещё до появления на рынке esp8266.
ignat99
16.06.2015 19:00У ESP8266 есть недостаток — слабый сигнал. Дальность 20 метров со стенами. Получается в каждое удалённое помещение ставить отдельный роутер? Поэтому переходят постепенно на другие платформы. А ESP8266 — для экстремально не дорогих решений.
imwode
16.06.2015 19:45esp долбит на километры
www.youtube.com/watch?v=7BYdZ_24yg0ignat99
16.06.2015 19:56Это в идеальных условиях на открытом воздухе около 300 метров (без других WiFi сигналов на том же диапазоне) и со специальными антеннами и без стен и зелени. Я не знаю как они измеряли расстояние в первом фрагменте, но двигались они по окружности дороги.
В реальных условиях, когда вокруг десятки сетей и в помещении ещё 2 сегмента WiFi на роутерах Motorola_AP5131 плюс соседние сети плюс коммерческие, реальная дальность 25 метров и 3 бетонных стены включительно и масса металических шкафов склада.imwode
16.06.2015 20:07Ну там же в конце данные — с внешней антенной и с pcb и сравнение с роутером ТП-линк. 3 с лишним км на своей антенне.
Ой, тупанул. 400м с обычным роутером и 3,6 км с тарелкой.ignat99
16.06.2015 20:22Да там они использовали отражатель с приличной площадью (вероятно вы его тарелкой называете, а я специальной антенной).
У полосковых и сегментных (спиральных) антеннах для самого ESP8266 так же есть специфика в диаграммах направленности и пр.
Исходники частного решения систем уравнений для этих антен на Python можно посмотреть тут.
DarkByte
16.06.2015 20:39Но ведь esp8266 может одновременно работать в режиме клиента и точки доступа, а значит ничего не мешает сделать mesh и обойтись либо вообще роутера (зачем умному дому интернет?), либо с одним роутером, через который вся сеть будет общаться с интернетом или локальным контроллером.
ignat99
16.06.2015 20:54+1Да можно сделать. У Souliss есть такая попытка. Вы попробуйте сделайте сами и желательно сразу передайте код в OS. Думаю это может занять от 1 месяца (в случае использования частей готового кода) до 1 года. То есть около $25 000. Видимо поэтому ещё не сделали. Или просто мне не известны такие решения. IMHO
DarkByte
16.06.2015 21:30Наверняка ещё не сделали лишь потому, что хотя китайцы и написали единичку в мажорной версии своего SDK, но на самом деле «ноль пишем, один в уме». Боятся чего то, не выкладывают сорцы для своих обёрток и костылей, от которых больше пользы или вреда, не понятно. Пока что у меня лично не появилось необходимости в дополнительных точках, одного роутера, висящего посередине деревянного дома вполне хватило чтобы не только покрыть его полностью, но и иметь стабильную связь на расстоянии метров 50 от него с модулем «01» (в метрах 100 связь по прежнему есть, но esp периодически самопроизвольно ребутается). Но так как это занятие лишь хобби и никакого дохода не приносит, то занимаюсь я им в свободное от работы время и по возможности делюсь результатами с общественностью.
DataArt Автор
17.06.2015 13:45Дальность приёма — понятие растяжимое, зависящее от множества факторов. Но прелесть использования Wi-Fi в том, что он уже очень часто есть готовый. Наверняка у 99.9 % читателей он есть дома. Для удалённых помещений, будь то Wi-Fi или любой другой способ связи, всегда будут возникать трудности с прокладкой проводов/установкой шлюза, причем роутер Wi-Fi — одно из самых недорогих решений.
AngelOfSnow
16.06.2015 21:32Все эти умные дома какие-то бестолковые, сводятся к включении кофеварок, света, набора ванны и т.д. и т.п., хоть раз бы описали действительно интересную задачу, решаемую этим домом) хотя б в теории)
Jeditobe
16.06.2015 22:20Собственно, чтоб далеко не ходить, вот эти наборы датчиков на Амазоне:
От 20 долларов за набор.
devlev
17.06.2015 13:14А если не сложно, можно сюда же ссылки на все остальное детали докидать? Для начала хотя бы набор для изготовления выключателя лампочки. Я так понимаю там ведь нужен сам чип + прошиватель (да простят меня гики, если что не так сказал). Тема на самом деле реально крутая и очень приятно что все начинает сводится к тому что вот тебе пару датчиков, вот тебе контроллер, просто вотки провода друг в друга и будет тебе моргающая лампочка.
doom369
17.06.2015 13:29Тогда Вам так же будет интересно взглянуть на www.blynk.cc там все еще проще.
Jeditobe
17.06.2015 15:53
hexenmeister
16.06.2015 22:29Сделать свой дом поистине «умным» можно и без использования модных Raspberry Pi или Arduino.
Можно, но сложно. Для действительно «умного» дома нужна вычислительная мощность, а ее у esp8266 всеже маловато. Про «облако» конечно ясно, но мне например совсен не улыбается видеть управление моего жилища на чужих серверах в интернете. Ну или интернет упадет. Значит всеже нужен локальный сервер. Тут-то Raspberry и пригодится. Хотя я предпочитаю Cubietruck.
А совсем без центрального сервера (на одних напрямую связанных отдельных модулях) ничего особо умного, боюсь, не получится.
Или как например реализовать следующий функционал:
Дано: электронно управляемые наружные залюзи, сенсоры освещенности, температуры, датчики движения.
Задача: при высокой температуре и яркости солнца частично закрывать жалюзи для предотвращения перегрева помещений. Разумеется для всех окон отдельно. Для этого расчитывается положение и высота солнца и на основании этого вычисляется, насколько сильно солнце «заглядывает» в комнату. На основании датчиков движения в комнатах система пытается действовать максимально незаметно (в зависимости от выбранного пользователем режима). и т.д.ignat99
17.06.2015 12:23Можно просто к термостату c веб-интерфейсом на ESP8266 подключить управление жалюзями, датчики движения — всё через I2C. Сигнал от сенсоров освещённости, кстати, можно взять либо от наружных камер, либо вычислить на основе широты места и времени суток и прогноза погоды :-), либо сенсор освещённости встроен в датчик движения и сигнал можно взять из датчика.
hexenmeister
17.06.2015 14:28Можно наверное, но ведь получится инвалидная коляска на костылях. В чем преимущество перед централизированным управлением?
Вычисления освещенности отметем сразу как совершенно негодные для данной цели. Тут нужны реальные данные. Вычисления (даже с учетом локальной погоды из интернета) я уже пробовал для определения времени закрытия залюзи на ночь. Даже для этого абсолютно не достаточно.
Здесь что получается? На каждое окно собственный веб-интерфейс? Да еще со своим полным комплектом датчиков? Вместо того, чтобы все данные (и веб-интерфейс) предоставлять центрально? Смысл-то где?
Освещенность от датчика движения кстати не годится. Это же освещенность в помещении, а нужна интенсивность наружнего солнечного излучения.
ignat99
17.06.2015 14:44Веб интерфейс на ESP8266 много места не занимает. Там ещё API есть на POST запросах, поэтому отдельного комплекта сенсоров не надо, достаточно управлять с IP модуля видеокамеры (использовать в качестве сервера). Для видеокамер тоже есть прошивки. На юге жалюзи почти всегда закрыты, открывают часто только для проветривания утром и если нужно естественное освещение днём, то их просто приоткрывают до появления отверстий. То есть настройки зависят от владельца и сильно отличаются для каждого конкретного случая. Где то управление жалюзями окон спаренное по 2 окна, где то шина используется типа матрица. IMHO
hexenmeister
17.06.2015 14:52Ну зачем костыльное решение, если можно нормальный сервер поставить?
ignat99
17.06.2015 15:02У меня на камерах стоит 1 модуль A20. Говорят в 4 раза быстрее RPi, при той же цене. Но на камере за 17 евро то же можно запустить веб сервер :-)
hexenmeister
17.06.2015 17:22У меня тоще А20 (Cubietruck). Быстрее первого Pi намного, второй версии — пожалуй нет.
ignat99
17.06.2015 17:57Согласен, только у меня OLinuXino. Очень порадовал настроенный rtps стрим сервер прямо в заводском имидже и возможность батареи подключать. Можно вместо блока питания сразу включить солнечную панель. Не одной заминки не с чем из драйверов, пока не было.
hexenmeister
17.06.2015 21:54Тоже неплохой девайс. Жаль только, что производитель с памятью пожадничал.
ignat99
17.06.2015 22:02Вроде всё в порядке с памятью. 1GB DDR3 RAM memory, 4GB NAND Flash, SD card.
hexenmeister
17.06.2015 23:42А, ОК, у Лиме2 1GB. И цена приятная.
При быстром поиске мне попалась первая версия с 512Кб. Этого мне было бы маловато.
DataArt Автор
17.06.2015 13:49А вот тут и начинаются прелести использования DeviceHive в качестве сервера. DeviceHive можно развернуть на любом сервере с помощью докера за считанные минуты — registry.hub.docker.com/u/devicehive/devicehive
При этом нет никакой необходимости в интернете. Иначе говоря, инфраструктура может находиться целиком внутри локальной сети.
Производить сколько-нибудь сложные вычисления на esp8266, разумеется, не стоит, т. к., например, в случае изменения алгоритма придется перепрограммировать каждую, а в случае сервера — все управление на нём. esp8266 — лишь прозрачный шлюз между электрическими сигналами и программой, а сервер — центр управления.ignat99
17.06.2015 14:05Я не пробовал использовать DeviceHive, не смогу оценить все плюсы решения. Просто для информации, например Souliss вообще не требует сервера. Все управляющие программы запускаются внутри Андроид приложения, включая веб-сервер с API интерфейсом. Так же предусмотрен обмен конфигурациями и самомаршрутизирующаяся меш сеть.
hexenmeister
17.06.2015 14:34Просто для информации, например Souliss вообще не требует сервера. Все управляющие программы запускаются внутри Андроид приложения, включая веб-сервер с API интерфейсом.
Т.е. этот андроид нужно будет навечно прибить на стену (чем мы получим центральный сервер, только на основе Андроид).
В другом случае кому-нибудь придет в голову взять этот Андроид с собой из дому (алтернативно: уронить на пол, забыть зарядить, разбить о стену) и весь дом останется без автоматики.
Ненадежное какое-то это решение, непрофессиональное…
hexenmeister
17.06.2015 14:17А вот тут и начинаются прелести использования DeviceHive в качестве сервера.
Вот и я о том, что без (центрального) сервера никуда.
doom369
17.06.2015 00:50-1Может я чего-то не понял, но таких вот REST клаудов уже полно и с огромными инвестициями, в чем преимущество DeviceHive?
DataArt Автор
17.06.2015 13:50Возможность выбора — всегда хорошо. 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 в коммерческих проектах. Более того, на примере этой прошивки мы предлагаем комплексное решения для реального железного воплощения интернет вещей, а не просто абстрагированный от реального оборудования клауд.
FilimoniC
17.06.2015 08:19что у него с безопасностью? очередная дырявая поделка или продумали?
DataArt Автор
17.06.2015 16:07Аутентификация на сервере происходит при помощи DeviceId и DeciveKey, т. е. имя пользователя/пароль. Устройство фактический является пользователем в системе DeviceHive. В DeviceHive имеется продуманная модель безопасности, которая позволяет ограничивать доступ к сетям, устройствам, вызовам API, фильтровать по IP/доменам, ограничивать количество попыток входа в систему, блокирование попыток подбора пароля, SSL/TLS-подключения.
northbear
20.06.2015 08:16Это все прекрасно, но частотный диапазон WiFi в обычном многоквартирном доме засран, дальше некуда… Обеспечить надежную работу системы в таких условиях будет реальной проблемой…
gleb_l
Отличное решение — когда-то разработчик, желающий вывести в Интернет свое устройство (если на борту был не *nix, конечно) был вынужден применять WiFi <-> UART или WiFi <-> SPI конвертеры по $30 за штуку (или как вариант — Zigbee за столько же и RaspPi как мост Zigbee — WiFi), плюс реализовывать кастомную логику обмена на серверной и клиентских (а на клиенте с ресурсами всегда напряг) сторонах.
С DeviceHive же для простых применений (типа открыть-закрыть жалюзи в комнате, включить-выключить кран, измерить температуру/освещенность), как я понимаю, даже не нужен отдельный МК — так как код выполняется в самом ESP8266, и если хватает выводов на простые функции, то за пару долларов реализуется полноценный IoT-enabled DIY-контроллер — что-то наподобие electricimp, только не требующий SD-сокета и технологической платы.
BTW, а как решается вопрос конфигурации ESP8266 'с нуля' для подсоединения к WiFi-сети?
DataArt Автор
Совершено верно: чтобы реализовать простейшее DIY-устройство, ничего, кроме esp8266, не нужно. Конфигурирование Wi-Fi сети и настроек сервера DeviceHive будет происходить через терминал по UART. В любом случае, в начале нужно прошить esp8266, а это делается через UART, т. е. можно, не отключая переходник от модуля, залить прошивку и сразу настроить её.
gleb_l
Эх, еще бы устранить слово 'переходник' и железо, которое за ним стоит — иначе получается, что если WiFi-роутер поменял SSID или пароль, нужно доставать из шкафа USB <-> RS232 девайс плюс RS232 <-> UART-3.3 конвертер, все это соединять, вынимать все ESP8266 из всех углов дома, и перепрошивать. Неудобно.
Вернее, так: начальную конфигурацию конечно делать неудобно, а вот реконфигурацию можно наверное сделать и средствами самого DeviceHive, предусмотрев соответствующую команду
DataArt Автор
Прошивка сейчас находится в разработке, и подобную команду для удаленной смены конфигурации, скорее всего, добавим на одном из этапов разработки. Но в любом случае стоимость USB->UART-переходника на Aliexpress, Ebay — от $1 с доставкой, соединять USB->RS232->UART нет никакого смысла.
toxicdream
Но «вынимать все ESP8266 из всех углов дома» все равно придется ведь…
ignat99
На ESP8266-EVB c этой прошивкой вопрос переконфигурации решается через удалённый WEB интерфейс и\или использованием аппаратной кнопки, которая меняет режим работы AP, ST, AP+ST.
DataArt Автор
Только если без вашего ведома неожиданно поменяли параметры Wi-Fi-сети. И то можно с ноутбуком пробежаться до каждого устройства, подключив три провода/разъем, прописать новые параметры.
А во всех остальных случая, можно дать команду на использование новой Wi-Fi-сети удалено, затем поменять параметры роутера, и все девайсы прицепятся к новой сети.
imwode
В примерах SDK есть схема, когда несконфигурированный модуль становится AP. Подсоединяетесь к этой АП, конфигурите вайфай, ребутитесь, модуль в режиме клиента и цепляется у сети. Наменого удобнее, чем через терминал…