Вот gist.github.com/belovictor/76e696c06b7c239447ea скетч для CC3200 Launchpad как раз для работы с openHAB по MQTT. На Arduino будет всё то же самое (ну только библиотеки сетевые по другому могут называться). На стороне openHAB всё настраивается по документации на mqtt binding — github.com/openhab/openhab/wiki/MQTT-Binding
Смотреть раздел «Event Bus Binding Configuration», чтобы на каждый item не прописывать конфигурацию mqtt.
Ну я спорить не буду, но сообщество в openHAB очень оперативно отвечает почти на все вопросы. Это, безусловно, решение не для домохозяйки, но мы такой задачи перед собой и не ставили. Я и не говорю что Иридиум должен быть бесплатным. Я скорее объясняю почему openHAB это не Иридиум. Все фичи openHAB драйвятся его пользователями. Когда кому то чего то не хватает — он просто это дописывает, ну или по крайней мере делает какой то изначальный вброс кода, который потом дорабатывает сообщество. Примерно раз в год кто нибудь говорит «а вот был бы полностью кастомизируемый интерфейс», но видимо пока никому он не нужен был настолько, чтобы его дописать :-)
MQTT запустить довольно просто. Можно на ubuntu поставить mosquitto — там даже настраивать особо нечего. У меня стоит несколько arduino по разным углам и через MQTT общается с openHAB. В ГРЩ стоит Arduino-Ethernet-PoE с LCD экраном и показывает текущие напряжения/токи по всем трём фазам, которые попадают в openHAB со счётчика через KNX :-)
А вчера вот запустил еще интересную платку — www.ti.com/tool/cc3200-launchxl — она на относительно новом чипе TI 3200 сделана. Там в одном корпусе ARM процессор и WiFi чип. Интересно то, что с недавних пор она поддерживается в Energia (http://energia.nu/) — это такая Ардуинистая среда для TI'евских плат и чипов. Почти любая библиотека для Arduino будет работать, например вот эта MQTT библиотека — github.com/knolleary/pubsubclient — просто заработала с WiFi библиотекой из Energia, и теперь можно через WiFi датчики цеплять, там где есть питание, но нет Ethernet.
Ну тут ведь какая проблема. Нужно как то научиться встраивать контекст дома в голосового ассистента. Apple вот для себя решил это просто — идите все свои приложения и системы загоняйте в homekit, и тогда Siri будет понимать что вы хотите от своего дома :-) Я к тому что тут нужно не только на стороне дуси что то сделать, но и на стороне openHAB, чтобы экспортировать его контекст в дусю, и она понимала чего ты от неё хочешь.
Я думаю что не может, а нужет! В ESH/openHAB 2.0 там вообще еще новая концепция добавилась — items объединяются в things, будет поддержка нормального автодискавери с последующим конфигурированием новых устройств. Еще мы съели jmdns брошенный и пытаемся под себя cling подмять для upnp :-) Основная масса контрибьюторов сейчас вдарилась в написание bindings. Кай занят ESH и openHAB 2.0, Томас с трудом успевает обслуживать текущий код 1.5-1.6 и делать ревью. Есть несколько человек которые контрибьютят в новое ядро, потом сейчас еще habmin появился — веб-интерфейс для конфигурации самого openHAB. Так что хороших людей не хватает!
Ну в принципе да. Но HTML знаете ли тоже разметка. Мы просто стараемся блюсти consistency пользовательского опыта на разных платформах. Смотришь в iOS, смотришь в Android, всё соответствует целевым дизайнам этих платформ, но при этом у человека не возникает ощущения что это два разных приложения. У многих например в доме есть устройства разных производителей — у человека Android, у жены iPhone, а сайтмап рисуется один раз. Ну и потом многие секции sitemap ведь могут генерироваться автоматически из групп, иначе офигеешь всё вручную отрисовывать. Мне например решения где надо сидеть и часами расставлять на экранах выключатели и т.п. не нравятся.
С Дусей не знаком, наверное могла бы. Есть примеры массы немецких товарищей, которые всякие автоматоры на Android интегрируют с нашим приложением через intent.
На самом деле, если у вашего TTS есть CLI или HTTP интерфейс, ничто не мешает прицепить его через command или http binding. Вот просто совсем ничего не мешает. У меня например TTS на 8 зон вещает через сетевые плееры Sonos Connect Amp. В sonos binding есть команда playUrl. Я беру Url API из Google Translate который на туче языков умеет говорить, с нужным текстом, и скармливаю его Sonos'ам. И они у меня разговаривают. Можно элементарно то же самое на mpd сделать — есть mpd binding, там тоже можно дать команду проигрывать любой URL, и любой компьютер с mpd заговорит.
А, да, про Oracle — да, я имею ввиду бесплатную версию. Да какая разница сколько и чего она жрёт? Есть конкретное применение — берём Raspberry Pi, одну из самых слабеньких встроенных платформ и по процессору, и по памяти, на ней всё работает. Можно до бесконечности дискутировать о том, что что то будет жрать меньше. Можно взять и всё то же самое написать на C++ например. Оно точно будет жрать гораздо меньше. Задача то не в этом, а в том чтобы сделать модульную гибкую систему для IoT и умных домов — пожалуйста, всё модульное, нужно что то своё — взял и дописал. Многоплатформенную, чтобы можно было на разных системах запускать — пожалуйста, работает на Linux, Linux embedded, Windows, OS X. И так далее. Давайте зайдём с другой стороны — чем плохо Java? Чем плохо OSGi? :-)
Я думаю основная причина, конечно, в том, что те кто начинал проект, писали на Java, вот и openHAB получился на Java :-) Хотя Java тут конечно скорее следствие OSGi. OSGi от стремления к модульности. Есть набор core бандлов, всё остальное — модульная архитектура. Надо — включил. Не надо — выключил. При этом надо не забывать что на момент начала этого проекта кроме Java/OSGi больше в общем то ничего и не было аналогичного наверное. Фиг знает, может быть если сейчас писалось бы, написалось бы например на nodejs. Тут ведь вопрос не в том на чём оно написано, а в том как оно написано, и что оно умеет делать. Написано оно очень хорошо, умеет делать оно очень многое и делает всё это очень хорошо. Значит задачу свою решает :-)
Насколько я понял из их сайта и документации, получается нужно два адаптера в компьютер втыкать — один для передачи команд, второй для их приёма. Протокол там тривиальный. Можно посмотреть как работает Z-Wave, Zigbee binding в openHAB, с помощью библиотеки RXTX, и реализовать это в своём binding.
Вообще, конечно, самый правильный способ прицепить к openHAB какую либо новую систему, это написать под неё binding. Если есть опыт Java это не составляет особого труда. В проекте есть maven archetype для стандартного binding который автоматом генерирует всю необходимую обёртку и дальше остаётся только реализовать новый протокол и прицепить его к стандартным компонентам openHAB. Если будет интересно я могу более подробно рассказать как binding стыкуются с системой, там реально ничего сложного нет. В Z-Wave например, который я начинал писать в своё время, 99% дела был сам Z-Wave, который пришлось частично реверс инженерить. Так что если есть понимание протокола этого noolight то всё делается очень легко.
Спасибо!
Смотреть раздел «Event Bus Binding Configuration», чтобы на каждый item не прописывать конфигурацию mqtt.
postscapes.com/internet-of-things-award/2014/iot-open-source-project
postscapes.com/internet-of-things-award/2014/iot-open-source-project
А вчера вот запустил еще интересную платку — www.ti.com/tool/cc3200-launchxl — она на относительно новом чипе TI 3200 сделана. Там в одном корпусе ARM процессор и WiFi чип. Интересно то, что с недавних пор она поддерживается в Energia (http://energia.nu/) — это такая Ардуинистая среда для TI'евских плат и чипов. Почти любая библиотека для Arduino будет работать, например вот эта MQTT библиотека — github.com/knolleary/pubsubclient — просто заработала с WiFi библиотекой из Energia, и теперь можно через WiFi датчики цеплять, там где есть питание, но нет Ethernet.