Comments 69
Отличное решение — когда-то разработчик, желающий вывести в Интернет свое устройство (если на борту был не *nix, конечно) был вынужден применять WiFi <-> UART или WiFi <-> SPI конвертеры по $30 за штуку (или как вариант — Zigbee за столько же и RaspPi как мост Zigbee — WiFi), плюс реализовывать кастомную логику обмена на серверной и клиентских (а на клиенте с ресурсами всегда напряг) сторонах.
С DeviceHive же для простых применений (типа открыть-закрыть жалюзи в комнате, включить-выключить кран, измерить температуру/освещенность), как я понимаю, даже не нужен отдельный МК — так как код выполняется в самом ESP8266, и если хватает выводов на простые функции, то за пару долларов реализуется полноценный IoT-enabled DIY-контроллер — что-то наподобие electricimp, только не требующий SD-сокета и технологической платы.
BTW, а как решается вопрос конфигурации ESP8266 'с нуля' для подсоединения к 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, предусмотрев соответствующую команду
Вернее, так: начальную конфигурацию конечно делать неудобно, а вот реконфигурацию можно наверное сделать и средствами самого DeviceHive, предусмотрев соответствующую команду
Прошивка сейчас находится в разработке, и подобную команду для удаленной смены конфигурации, скорее всего, добавим на одном из этапов разработки. Но в любом случае стоимость USB->UART-переходника на Aliexpress, Ebay — от $1 с доставкой, соединять USB->RS232->UART нет никакого смысла.
Но «вынимать все ESP8266 из всех углов дома» все равно придется ведь…
UFO just landed and posted this here
Только если без вашего ведома неожиданно поменяли параметры Wi-Fi-сети. И то можно с ноутбуком пробежаться до каждого устройства, подключив три провода/разъем, прописать новые параметры.
А во всех остальных случая, можно дать команду на использование новой 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
Или так — DeviceHive имеет команду, указывающую устройству период активизации — таким способом можно динамически конфигурировать оперативность отклика того или иного устройства прямо с сервера. Вот здесь был пост о питании ESP8266 от солнечных батарей — там может сильно пригодиться.
И последняя идея — для всех мобильных устройств и особенно wearables контроль энергопотребления — первоочередная задача, так как в сегодняшнем КМОП-мире объем вычислений — практически линейная функция от запасенной в батарее энергии. Почему бы не ввести в «ядро» DeviceHive функции управления питанием, как это сделано в мобильных операционных системах — тогда подобные базовые вещи были бы реализованы из коробки универсальным образом, и это открыло бы дорогу к автономным применениям IoT — то есть к тому, что сейчас является последним камнем преткновения широкому распространению IoT-enabled систем? Еще один камень — 1-dollar IoT chip — практически уже преодолен, в частности, как раз средствами ESP8266, и не в последнюю очередь, как я понимаю, усилиями DeviceHive
Почти все то что тут описано уже реализовано в этой прошивке(+возможность обновления по воздуху). Единственное прошивка там закрытая, но текущий функционал просто огромен.
Там ведь даже спящий режим за деньги, не смотря на то, что это вызов всего одной функции на сях. Да и большая часть функционала той прошивки доступна на github в виде различных проектов и примеров, стоит лишь собрать их воедино. Для этого конечно потребуется знание и умение программировать.
Спящий режим очень проблемная штука, кроме самого контролера надо еще отключать питание датчиков, у разных датчиков разное время выхода на рабочий режим, в итоге очень много нюансов и не достаточно отправлять в сон только сам контролер. Ну стоимость которую просит автор за доп функционал достаточно скромная!
UFO just landed and posted this here
esp долбит на километры
www.youtube.com/watch?v=7BYdZ_24yg0
www.youtube.com/watch?v=7BYdZ_24yg0
Но ведь esp8266 может одновременно работать в режиме клиента и точки доступа, а значит ничего не мешает сделать mesh и обойтись либо вообще роутера (зачем умному дому интернет?), либо с одним роутером, через который вся сеть будет общаться с интернетом или локальным контроллером.
UFO just landed and posted this here
Наверняка ещё не сделали лишь потому, что хотя китайцы и написали единичку в мажорной версии своего SDK, но на самом деле «ноль пишем, один в уме». Боятся чего то, не выкладывают сорцы для своих обёрток и костылей, от которых больше пользы или вреда, не понятно. Пока что у меня лично не появилось необходимости в дополнительных точках, одного роутера, висящего посередине деревянного дома вполне хватило чтобы не только покрыть его полностью, но и иметь стабильную связь на расстоянии метров 50 от него с модулем «01» (в метрах 100 связь по прежнему есть, но esp периодически самопроизвольно ребутается). Но так как это занятие лишь хобби и никакого дохода не приносит, то занимаюсь я им в свободное от работы время и по возможности делюсь результатами с общественностью.
Дальность приёма — понятие растяжимое, зависящее от множества факторов. Но прелесть использования Wi-Fi в том, что он уже очень часто есть готовый. Наверняка у 99.9 % читателей он есть дома. Для удалённых помещений, будь то Wi-Fi или любой другой способ связи, всегда будут возникать трудности с прокладкой проводов/установкой шлюза, причем роутер Wi-Fi — одно из самых недорогих решений.
Все эти умные дома какие-то бестолковые, сводятся к включении кофеварок, света, набора ванны и т.д. и т.п., хоть раз бы описали действительно интересную задачу, решаемую этим домом) хотя б в теории)
А если не сложно, можно сюда же ссылки на все остальное детали докидать? Для начала хотя бы набор для изготовления выключателя лампочки. Я так понимаю там ведь нужен сам чип + прошиватель (да простят меня гики, если что не так сказал). Тема на самом деле реально крутая и очень приятно что все начинает сводится к тому что вот тебе пару датчиков, вот тебе контроллер, просто вотки провода друг в друга и будет тебе моргающая лампочка.
Сделать свой дом поистине «умным» можно и без использования модных Raspberry Pi или Arduino.
Можно, но сложно. Для действительно «умного» дома нужна вычислительная мощность, а ее у esp8266 всеже маловато. Про «облако» конечно ясно, но мне например совсен не улыбается видеть управление моего жилища на чужих серверах в интернете. Ну или интернет упадет. Значит всеже нужен локальный сервер. Тут-то Raspberry и пригодится. Хотя я предпочитаю Cubietruck.
А совсем без центрального сервера (на одних напрямую связанных отдельных модулях) ничего особо умного, боюсь, не получится.
Или как например реализовать следующий функционал:
Дано: электронно управляемые наружные залюзи, сенсоры освещенности, температуры, датчики движения.
Задача: при высокой температуре и яркости солнца частично закрывать жалюзи для предотвращения перегрева помещений. Разумеется для всех окон отдельно. Для этого расчитывается положение и высота солнца и на основании этого вычисляется, насколько сильно солнце «заглядывает» в комнату. На основании датчиков движения в комнатах система пытается действовать максимально незаметно (в зависимости от выбранного пользователем режима). и т.д.
UFO just landed and posted this here
Можно наверное, но ведь получится инвалидная коляска на костылях. В чем преимущество перед централизированным управлением?
Вычисления освещенности отметем сразу как совершенно негодные для данной цели. Тут нужны реальные данные. Вычисления (даже с учетом локальной погоды из интернета) я уже пробовал для определения времени закрытия залюзи на ночь. Даже для этого абсолютно не достаточно.
Здесь что получается? На каждое окно собственный веб-интерфейс? Да еще со своим полным комплектом датчиков? Вместо того, чтобы все данные (и веб-интерфейс) предоставлять центрально? Смысл-то где?
Освещенность от датчика движения кстати не годится. Это же освещенность в помещении, а нужна интенсивность наружнего солнечного излучения.
Вычисления освещенности отметем сразу как совершенно негодные для данной цели. Тут нужны реальные данные. Вычисления (даже с учетом локальной погоды из интернета) я уже пробовал для определения времени закрытия залюзи на ночь. Даже для этого абсолютно не достаточно.
Здесь что получается? На каждое окно собственный веб-интерфейс? Да еще со своим полным комплектом датчиков? Вместо того, чтобы все данные (и веб-интерфейс) предоставлять центрально? Смысл-то где?
Освещенность от датчика движения кстати не годится. Это же освещенность в помещении, а нужна интенсивность наружнего солнечного излучения.
А вот тут и начинаются прелести использования DeviceHive в качестве сервера. DeviceHive можно развернуть на любом сервере с помощью докера за считанные минуты — registry.hub.docker.com/u/devicehive/devicehive
При этом нет никакой необходимости в интернете. Иначе говоря, инфраструктура может находиться целиком внутри локальной сети.
Производить сколько-нибудь сложные вычисления на esp8266, разумеется, не стоит, т. к., например, в случае изменения алгоритма придется перепрограммировать каждую, а в случае сервера — все управление на нём. esp8266 — лишь прозрачный шлюз между электрическими сигналами и программой, а сервер — центр управления.
При этом нет никакой необходимости в интернете. Иначе говоря, инфраструктура может находиться целиком внутри локальной сети.
Производить сколько-нибудь сложные вычисления на esp8266, разумеется, не стоит, т. к., например, в случае изменения алгоритма придется перепрограммировать каждую, а в случае сервера — все управление на нём. esp8266 — лишь прозрачный шлюз между электрическими сигналами и программой, а сервер — центр управления.
UFO just landed and posted this here
Просто для информации, например Souliss вообще не требует сервера. Все управляющие программы запускаются внутри Андроид приложения, включая веб-сервер с API интерфейсом.
Т.е. этот андроид нужно будет навечно прибить на стену (чем мы получим центральный сервер, только на основе Андроид).
В другом случае кому-нибудь придет в голову взять этот Андроид с собой из дому (алтернативно: уронить на пол, забыть зарядить, разбить о стену) и весь дом останется без автоматики.
Ненадежное какое-то это решение, непрофессиональное…
А вот тут и начинаются прелести использования 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 в коммерческих проектах. Более того, на примере этой прошивки мы предлагаем комплексное решения для реального железного воплощения интернет вещей, а не просто абстрагированный от реального оборудования клауд.
Множество частных компании используют DeviceHive в коммерческих проектах. Более того, на примере этой прошивки мы предлагаем комплексное решения для реального железного воплощения интернет вещей, а не просто абстрагированный от реального оборудования клауд.
что у него с безопасностью? очередная дырявая поделка или продумали?
Аутентификация на сервере происходит при помощи DeviceId и DeciveKey, т. е. имя пользователя/пароль. Устройство фактический является пользователем в системе DeviceHive. В DeviceHive имеется продуманная модель безопасности, которая позволяет ограничивать доступ к сетям, устройствам, вызовам API, фильтровать по IP/доменам, ограничивать количество попыток входа в систему, блокирование попыток подбора пароля, SSL/TLS-подключения.
Это все прекрасно, но частотный диапазон WiFi в обычном многоквартирном доме засран, дальше некуда… Обеспечить надежную работу системы в таких условиях будет реальной проблемой…
Здравствуйте! Может быть интегрируем DeviceHive в MajorDoMo? Почему бы не предоставить ещё одну опцию для пользователей по построению домашней сети сенсоров.
А возможна ли работа ESP8266 с обычными бескорпусными видеокамерами, или не хватит производительности для обработки H264 потока? И если нет, то к какой плате можно присматриваться для решения этой задачи?
UFO just landed and posted this here
Подскажите, а есть устройства с GPIO на подобии ESP8266, но исспользуещие BLE вместо WiFi?
Из-за высокого потребления электроэнергии ESP8266 не совсем идеальное решение. Другими словами ESP8266 будет всегда исспользоваться только там, куда можно подвести питание или куда можно установить относительно крупную батарею.
И соответственно в продолжение предыдущей мысли, логично предположить, что эта проблема могла бы быть решена заменой WiFi на BLE.
Из-за высокого потребления электроэнергии 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, или написать приложение, берущее данные с сервера DeviceHive и управляющее этим контроллером.
Организовать работу с любыми сторонними контролерами возможно. Нужно либо научить контроллер использовать DeviceHive, или написать приложение, берущее данные с сервера DeviceHive и управляющее этим контроллером.
Sign up to leave a comment.
IoT за копейки, или Что может DeviceHive