Пользователь
0,0
рейтинг
15 июля 2014 в 01:17

Разработка → Никогда не «не делай» того, о чем пожалеешь или умный дом с CCU.IO

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

Хочу представить программную платформу автоматизации для дома на базе Node.js, которую можно скачать со всеми исходниками и установить прямо сейчас практически одним кликом (Windows) или одной командой (Linux/Debian).



У некоторых возникнет, вполне уместный вопрос: зачем мне (нам) рассказывать о своей системе?

Я вижу с какими «половинчатыми» решениями живут энтузиасты автоматизации домов и хочу предложить законченное решение для комплексного программного обеспечения автоматизации дома. От драйверов — до скриптов и визуализации. Все компоненты системы имеют лицензию либо MIT либо CC NC BY. Что значит, для не коммерческого использования абсолютно бесплатно, хотя система включает в себя 3 человека-«хобби»-лет разработки. Я сам инвестировал в систему 1 год разработки по 2 часа в день (каждый день, включая выходные).

Для понимания контекста можно прочитать первые три абзаца предыдущей статьи. Данная статья является продолжением.

Вступление

Представленная система — это уже третья итерация системы автоматизации в моем жилище.

Первая была: X10 + HTTP Requests,
вторая: HomeMatic + PHP/MySQL (про них можно почитать в предыдущем моём посте)
и вот третья: HomeMatic + NodeJS / JavaScript.

Разработка этой системы началась в январе 2013, хотя активный рост начался в мае 2013 и сейчас над системой регулярно (каждый день) работают 3 разработчика и рук на всё уже не хватает.

Лирическое отступление

Можно не читать
Когда я созрел для следующего шага в написании веб интерфейса для умного дома, я уже знал, что будущая система должна уметь в любом случае:

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

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

1. Jarvis

www.nextex-medienagentur.de/jarvis-v2 — (может упасть из-за нагрузки).

2. HCS — Home Control Suite (http://hcs.xenorate.com/)


3. Dash UI


Jarvis выглядит очень презентабельно. Человек, написавший этот интерфейс профессионально работает веб дизайнером. Но при более детальном изучении выяснилось, что это PHP+Apache+SQL, а главное, что положение+конфигурация всех объектов задана статически в HTML файле. А это мы уже проходили: при добавлении нового датчика нужно править HTML файл и потом муторно подгонять позиции и свойства объекта, через CSS или свойство style, т.к. визуальных средств проектирования для этой системы нет.

Home Control Suite написал тот же человек, что и основы моего прошлого интерфейса (http://habrahabr.ru/post/149716/). Он, видимо, тоже пришел к таким же заключениям, как и я, и уже год как работал над новой системой. Протестировав систему я понял, что это то что нужно, хотя настройки виджетов вызывали нарекания. Ничего, решил я: JS + PHP + SQL мы уже проходили и можно будет переписать или улучшить интерфейс до необходимого мне уровня.

Dash UI я протестировал тоже, но она была непрезентабельной и была на неизвестной мне платформе Node.js. На тот момент она разрабатывалась только 2 месяца, что тоже не внушало уверенности.

Попутно я выяснил, что разработчик HCS живет в моем городе. Какая удача, решил я: вот тут то мы сработаемся, тем более можно без труда встретиться и обсудить все offline. Хотя разработчик DashUI жил в соседнем городе, всё равно это было расстояние в 80 км и после работы уже просто так не встретишься.

Написав человеку с HCS о желании встретиться и о том, что не мог бы он выложить исходники куда нибудь на SVN, я получил ответ, что звонить не стОит, т.к. можно все обсудить по почте, а уж встречаться тем более смысла нет. Также он дал мне знать, что исходники я могу выложить сам, но он не обещает, что будет этим пользоваться. Хм…

Я написал человеку с DashUI и тут же получил письмо с ответом, что лучше всё обговорить по телефону, т.к. тема эта не простая. Мы прообсуждали час, потом у меня сел аккумулятор.

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

Хорошо, решил я, думая про HCS: не хочешь, не надо.

И взялся за Dash UI.

Прошёл год.

CCU.IO + Dash UI активно разрабатывает команда из 3х человек с уже 200-300 пользователями. HCS разрабатывает по прежнему один и имеет от силы 10 пользователей (Должен признаться я сам потом переманил 3-х на Dash UI).

При поездке на конференцию по автоматизации, разработчик Dash UI вызвался подбросить меня и разработчика HCS до места проведения конференции. Благо мы все на неё собирались. По дороге туда и на конференции (мы, кстати, делали там доклад) и по дороге обратно человек, отказавший мне в кооперации, был вынужден слушать наши обсуждения, планы, проблемы, задачки пользователей — постоянно. После того как мы приехали с конференции обратно, он сказал: «Ах как бы я хотел участвовать в проекте, как ваш. Жалко, что я тогда не позвонил...»


Описание системы


Цитата из документации:
CCU.IO это программа, написанная на Node.js и служащая для автоматизации различного домашнего (и не очень) оборудования.
При помощи встроенного веб-сервера CCU.IO выступает платформой для визуализации и позволяет отображать события с использованием Socket.IO библиотеки. Нет постоянных запросов к серверу (no-polling), а сервер сам говорит, когда нужно обновить графический элемент. Ресурсоёмкий процесс постоянных запросов отпадает и таким образом уменьшается время реакции на события. Дополнительно CCU.IO выступает, как прокси между визуализацией и приборами. Не важно, сколько запущено копий визуализации, нагрузка на приборы всегда одинаково низкая.

Можно подключать новое оборудование через, так называемые, драйверы. На данный момент существуют драйвера для Philips Hue, Sonos, IRTrans, подключение к базе данных MySQL, а также различных веб-сервисов (Погода, валюта, почта, pushover). Некоторые новые драйвера находятся в разработке или запланированы на ближайшее будущее.

Интегрированный в CCU.IO механизм скриптов позволяет автоматизировать системы при помощи языка JavaScript. Все возможности среды Node.JS можно использовать и в скриптах (например доступ к дисковой системе, сетевые функции и т.д.) Также можно использовать огромное количество готовых библиотек через npm.

CCU.IO это открытое программное обеспечение.


Взаимодействие компонентов можно представить таким образом:


Компоненты системы:

CCU.IO

1.CCU.IO — это ядро системы. Название CCU (Central Control Unit) пришло из HomeMatic, где CCU это центральный контроллер и gateway для связи по ethernet.
В данный момент ядро переписывается, что бы уйти от архитектуры HomeMatic и т. к. уже в сегодняшнем виде система поддерживает и другие системы автоматизации, то новая будет называться ioBroker.
Ядро написано на NodeJS/JavaScript и может быть запущено на почти любой платформе, для которой есть NodeJS бинарники. В настоящий момент высокая степень интеграции создана для Raspberry PI. Известно точно, что пользователи запустили систему на Windows, OSX, QNAP (ARM/Intell) Synology, Cubietrack, BananaPI, Odroid, Ubuntu (x86) und Debian.
CCU.IO является только связующим звеном между компонентами. Из него же происходит запуск драйверов (adapters) с указанными параметрами.

GitHub: https://github.com/hobbyquaker/ccu.io/blob/master/doc/README-ru.md

Драйвера

2. Драйвер или адаптер — это JavaScript файл, запускающийся в отдельном NodeJS процессе и обслуживающий одно устройство или службу. На данный момент созданы следующие драйвера:
email для отправки сообщений по электронной почте
pushover для отправки сообщений на мобильные клиенты (http://pushover.net)
mysql запись событий в базу данных
graphite пересылка событий в graphite (http://graphite.wikidot.com/screen-shots). Группировка данных в мыслимых и немыслимых формах и их отображение в виде графиков.
ical Google и Apple iCloud календари
geofency поддержка Apple системы геолокации geofency
growl сообщения на Apple Growl App
currency курсы валют с европейского центрального банка. (Есть EUR-RUB и USD-RUB)
telnet управление приборами по telnet протоколу
ping пингует IP устройства в сети
lirc для управления приборами и принятия команд по инфракрасному порту (требуется дополнительное железо)
irtrans поддержка IRTrans инфракрасной системы (http://www.irtrans.de/en/)
hue управление PhilipsHUE лампами
lgtv управление LG телевизорами по сети
denon управление DENON ресиверами
onkyo управление ONKYO ресиверами
yamaha управление YAMAHA ресиверами
sonos управление SONOS системой звука
dream управление DreamBOX спутниковыми ресиверами (http://ru.wikipedia.org/wiki/Dreambox)
owfs One Wire File System (http://owfs.org/) — сбор данных с датчиков Dallas/Maxim по 1-Wire
B-control Energy Manager мониториг расхода электроэнергии www.b-control.com/energiemanagement.html (нет описания на английском)
all3418v2 — ALLNET ALL3418v2 / IP Thermometer LAN / WLAN беспроводной термометр — www.allnet.de/en/allnet-brand/pr… r-lanwlan/
homepilot управление системой автоматизации Rademacher.
homematic управление системой автоматизации HomeMatic (встроено в CCU.IO).
rego мониторинг котлов Junkers TM75, IVT Rego 634
megaD поддержка MegaD-328.
rpi мониторинг основных параметров (CPU, Mem, Temperature) RaspberryPI. Поддержка 1-Wire интерфейса и PiFace.
cubie мониторинг основных параметров (CPU, Mem, Temperature, Battery) Cubietruck.
sayit голосовые сообщения (text2speech или wav) на системе(Linux, Windows, OsX) или android планшете (через Home24 Mediaplayer — play.google.com/store/apps/deta… ayer&hl=ru).
textCommands интерфейс для команд, заданных обычным текстом (Пример: Какая температура дома?)
owm OpenWeatherMap (http://openweathermap.org/) — погода по всему миру
yr погода с норвежского сервера www.yr.no
dwd официальные предупреждения о штормах в Германии
fritzBox отображение списка звонивших для fritzBox
speedport отображение списка звонивших для speedport
sun_and_time время захода и восхода солнца, а также праздничные дни для Германии
muell_stuttgart время вывоза мусора в Штутгарте


Создать собственный драйвер со знаниями системы, для которой создается адаптер, не составляет труда. Конечно, знания JavaScript на много облегчат задачу.
Есть демо драйвер с большим количеством объяснений из которого можно понять: как писать собственный драйвер.

Script Engine

3. Сценарии реакций на события (Собственно — автоматизация)
Script Engine тоже запускается в своем процессе, как драйвер и служит для выполнения пользовательских скриптов на JavaScript. Все скрипты лежащие в папке ccu.io/scripts будут запущены. Управление происходит следующим образом:

// Простые события
var swicthID = 79111; // Адрес кнопки
var actorID  = 80187; // Адрес силового реле

// подписываемся на нажатие кнопки
on(swicthID, function (obj) {
        // передаем состояние на реле
   setState(actorID, obj.newState.value);
});

// Можно так. Значение из адреса 79111 при изменении запишется в устройство или переменную по адресу 80187
on(79111, 80187);


Вот пример посложнее:
var postboxTimer = null;
var postboxSensorID = 61555; // ID датчика на почтовом ящике
subscribe(postboxSensorID, function (obj) {

   // Если таймер ещё не запущен
    if (!postboxTimer) {

      // Стартуем таймер на 30 секунд, что бы отбросить быстрые открытия/закрытия
        postboxTimer = setTimeout(function () {
            postboxTimer = null;
        }, 30000);

      // Увеличиваем счетчик
        setState(postboxStateID, 1 + getState(postboxStateID ));
    }
});

// При старте создаем собственную переменную в CCU.IO
setObject(postboxStateID , {
    Name: "Postbox.State",
    TypeName: "VARDP"
}, function () {
    setState(postboxStateID , 0);
});


Описание функций можно взять на git.

Для SctiprEngine написана визуальная система создания скриптов ScriptGUI, где всё программирование происходит визуально.

www.youtube.com/watch?v=xeBXTDaidbU&list=PLsNM5ZcvEidhmzZt_mp8cDlAVPXPychU7 — Внимание, видео на немецком.



В данный момент перевод идет полным ходом. Это снимок с незавершенным переводом, но кое что уже переведено.

Dash UI

4. Дополнение Dash UI (Читается Дэш-ЮАЙ) это система визуализации для умного дома.
Вот примеры интерфейсов созданных с помощью DashUI:












По адресу DashUI.ccu.io их можно потыкать и посмотреть на скорость. Хочу заметить, что отображение графиков и таблиц не работает в оффлайн режиме, так что не удивляйтесь, если некоторые страницы окажутся пустыми.

Есть даже такие реализации(в стиле Star Trek):





Есть видео создания простенького интерфейса с чистого листа:



Вот ещё несколько видео:

www.youtube.com/watch?v=viE5y8YmZo0&list=PLsNM5ZcvEidgGDCFnm23bub3Mj-ZU4Cp4 — Примеры
www.youtube.com/watch?v=gS-O5OKjQhk — Голосовые сообщения на немецком

Открыть дверь по NFC тэгу:



Недостатки дополнения в том, что интерфейс не масштабируется автоматически под экран. Но с другой стороны можно нарисовать 2 интерфейса: для таблета / десктопа и для телефона. Как многие и делают.

GitHub: github.com/hobbyquaker/DashUI

MobileUI

5. Дополнение MobileUI в данный момент называется Yet another home user interface — yahui. Но мне название режет ухо и мы скоро переименуем его в MobileUI.

Этот интерфейс выглядит в виде списка устройств. Можно назначить каждому устройству или комнате собственные картинки или переименовать. На этом конфигурация системы закончена.





Это дополнение (Add-on) использует jQuery Mobile и автоматически изменяется, в зависимости от устройства, где вызвана страница.



SlimUI

6. Интерфейс SlimUI — система веб визуализации на «Vanilla» Javasript для очень старых браузеров и слабых устройств. Никакие библиотеки (jQuery или подобные) не используются. Данные опрашиваются по таймеру (polling), а команды отдаются через RestAPI (SimpleAPI).

GitHub: github.com/hobbyquaker/SlimUI

SimpleAPI

7. SimpleAPI — Интерфейс основанный на HTTP-GET запросах вида:

http://ccu-io-host:ccu.io-port/api/get/950


где 950 — это индекс переменной из CCU.IO.

Ответ отдается в JSON формате или просто значение, как текст.
Управление выглядит вот так:

http://ccu-io-host:ccu.io-port/api/set/950/?value=1
http://ccu-io-host:ccu.io-port/api/set/Свет-кухня/LEVEL/?value=0.7


Используется для коммуникации CCU.IO с внешними программами, такими как Trigger или Tasker. Я, например, использую интерфейс для открытия замка двери по NFC тэгу, через Trigger.
Описание интерфейса можно взять на git.

CCU.IO-Highcharts

8. Дополнение CCU.IO-Highcharts.
Рисование графиков используя исторические данные, сохраненные CCU.IO.


GitHub: github.com/hobbyquaker/CCU-IO-Highcharts

Дополнение CCU.IO-Eventlist

9. Дополнение CCU.IO-Eventlist.
Используется для отображения событий записанных CCU.IO


Graphite

10. Адаптер Graphite.
Мощный инструмент визуализации данных, созданный другой командой. Может складывать графики и производить манипуляции с данными. Например, посчитать: сколько времени за последний месяц горели лампы в зале.



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

Эта система довольно объёмна и на мой взгляд требует отдельной статьи на хабре. Странно, что Graphite ещё ни кто не описал здесь.

graphite.wikidot.com/screen-shots
github.com/graphite-project/graphite-web

Реальное применение


Конечно, CCU.IO установлена у меня дома.
Даже дважды: рабочая система на Odroid/Linux (она редко изменяется и обновляется) и тестовая система на RaspberryPi (перезагружается и изменяется по несколько раз за вечер)

Системы работают параллельно не мешая друг другу и обеспечивают высокую доступность (redundancy) сервиса.

Лично мной используются следующие дополнения и драйвера:
Dash UI для визуализации на планшете и удаленного управления с телефона;
Highchart для представления графиков температур и влажности в визуализации;
Eventlist для отображения истории событий по одному датчику, например открытие/закрытие входной двери;
Script-Engine для генерирования текстовых сообщений для pushover, и вообще для связывания событий с действиями на эти события;
HomeListener App для управления голосом с таблета или телефона

ping для определения присутствия жены членов семьи дома. По IP адресу мобильного телефона можно определить — дома человек или нет;
pushover для текстовых сообщений на телефон: «Звонок в дверь», «Стирка закончена» или «Входная дверь открыта уже 10 минут. Надо проверить.»;
ccu для управления светом, рольставнями и отоплением. Информация о температуре и влажности, в каждой комнате и на улице, тоже поступает через этот драйвер;
ical для отображения запланированных событий и дней рождений на экране планшета;
sonos в основном, для индикации состояния проигрывателя, т.к. с родного приложения управлять удобнее;
fritzbox для получения списка звонков на домашний номер;
yahooWeather для информации о погоде;
lgtv для выключения телевизора при уходе из квартиры;
sayit для голосовых сообщений на планшете;
rpi для контролирования свободного места на RaspberryPi.
textCommands как точка подключения HomeListener App

Но это далеко не полный список сервисов, которые можно было-бы задействовать. Из-за огромного количества времени, уходящего на поддержку и разработку CCU.IO, нет возможности поиграться и реализовать систему на полную.
Как говориться: сапожник без сапог :)

Вообще я управляю системой редко. Она просто тихо мониторит все события и отдает по-тихому команды на исполнение: отопление, свет по датчику движения, информирует сообщениями о происходящем дома.

Итог


При помощи CCU.IO можно соединить воедино все компоненты умного дома и управлять ими. Можно создать различные визуальные графические интерфейсы или управлять системой через HTTP вызовы.
Есть даже интеграция голосового интерфейса, правда google тогда будет знать о чем говорят дома. (Ведётся проверка возможности использования оффлайн распознавания)



Ссылки



P.S.
Всегда завидовал аллизарам и компании, строчащим по 2 поста в день.
Написание 80-ти процентов этой статьи заняло 3 дня. Плюс 3 недели на доработку, дополнение и перевод документации.

При написании статьи были обнаружены следующие похожие проекты (некоторые были известны и до этого):
Node-RED — установленный локально IFTT (if than than that) Node.js проект. Недостатки: нет визуализации, хотя очень продуманный проект от инженеров IBM.
SmartVISU — красивая визуализация. Недостатки: заточен только под KNX устройства и компоновка/конфигурация виджетов только через конфигурационный текстовый файл.
MajorDoMo — визуализация и автоматизация. PHP и polling событий.
OpenHAB — сервер автоматизации на Java. Недостатки: рудиментарная визуализация
OpenRemote — ещё один сервер автоматизации на Java.
Freedomotic — новое open source программное обеспечение для автоматизации дома, распространяемое под лицензией GPL2, написанное на Java (что позволяет запускать его на Linux, Mac или Windows). Основная задача ПО — предоставить энтузиастам возможность самостоятельно создать систему умного дома, объединив самодельное оборудование или используя для этого готовые решения популярных архитектур. Также Freedomotic позволяет интегрировать умный дом с социальными сетями, интернет-сервисами и сторонними приложениями посредством развитого API.
Agocontrol — GNU GPL автоматизация на питоне
Ninja Blocks — автоматизация в облаке
Domoticz — автоматизация на C#
The Thing System — Отлично подходит для автоматизации, но нет визуализации.
и десятки других проектов.
Что бы расставить приоритеты в написании драйверов, сообщите, какие системы автоматизации стоят у вас дома?

Проголосовало 987 человек. Воздержалось 248 человек.

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

Денис @Bluefox
карма
66,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (81)

  • +1
    Imho, добавьте возможность лёгкого подключения своих модулей-самоделок к вашей системе.
    Простейшие варианты подключения девайсов к общей сети:
    1. ARM based (практически любой роутер с USB — начиная от DIR-320; всякие RaspBerry, CubieBoard и аналогичные платы для гиков) девайс, к которому подключен шлюз или собственный контроллер умного дома, при этом подключение может быть как по RS-232 (точнее — USB=>TTL переходник), так можно подключить обычную ардуинку, имеющую выход во внутреннюю сеть (там уже дальше может быть что угодно — RS-485, 1-wire, беспроводные модули со своими протоколами).
    Девайс довольно производителен, софт контроллера/шлюза к вашей платформе может крутиться на нём,… или даже вся платформа помещается целиком.

    2. Собственный контроллер с тупым Ethernet/Wifi «переходником», который умеет UDP/SNMP, а, возможно, даже TCP/HTTP.

    3. Какие-то стандартные протоколы подключения «умного дома» к сети.

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

    Вот тогда будет бомба… ладно, будет очень узкоспециализированная бомбочка для гиков, но гики скажут множество «спасибо».
    Лично я сейчас раздумываю над созданием своего собственного велосипеда со сбором информации (температура, влажность, давление, счётчики) и некоторым управлением (вентиляторы, лампочки)… в качестве шлюза в сеть будет плата с A20 на борту (CubieBoard).
    И красивый удобный интерфейс, который можно запустить на недорогом планшете для управления всем этим делом будет очень кстати.
    • 0
      3. Какие-то стандартные протоколы подключения «умного дома» к сети.

      Пока мы сосредоточились на этом.

      Чтобы просто взял, потратил пару вечеров и написал свой контроллер.

      Все на JS. Ну куда уж проще. :) У меня уходит 2 вечера на написание драйвера чего нибудь. Например, недавно интегрировал HomePilot. Следующим сделаю Harman/Kardon.
  • +6
    Я вижу с какими «половинчатыми» решениями живут энтузиасты автоматизации домов и хочу предложить законченное решение

    Простите, но я с этим немного не согласен. Не знаю как объяснить даже. Вот Android это «половинчатое» решение? Вроде есть ОС и ей можно по разному пользоваться. Только пару программ установить, заточить немного под себя…
    А Xiaomi его взяли и вынесли на новый уровень: купи с MiUi смартфон и сразу пользуйся. Хотя можно покопаться и будет удобнее… Законченное решение, это если ко мне в общагу придут крутые ребята в спецовках, установят сенсоры, розетки, выключатели и загрузят на все мои устройства программы по управлению, заодно заточив под мой распорядок жизни. Это будет законченное решение. Или вот 1С. Законченное решение?
    Тысячи программеров по всей стране бьются над ней уже больше десятка лет в полный рабочий день без сна и отдыха, тратятся сотни и тысячи человеко-часов, куча бабла уходит и на покупку и на сопровождение. Но хоть у кого-нибудь работает все «из-коробки» без обработки напильником, терзания саппорта и ****** с настройкой?

    Я не хочу уменьшить ваши заслуги: это круто и достойно уважения. Но пока нет полностью «законченных» решений в моём представлении, я буду упиваться фаном от разработки своей «половинчатости», но использовать её по полной, а не треть вашего решения.
    Удачи вам! (А лучше успехов) Надеюсь, что когда-нибудь я решу использовать именно ваше решение (лёгкость внедерения перевесит фан от прогинга)
    P.S. а жена то смирилась?
    • +1
      Я вижу с какими «половинчатыми» решениями живут энтузиасты автоматизации домов и хочу предложить законченное решение

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

      Простите, но я с этим немного не согласен. Не знаю как объяснить даже. Вот Android это «половинчатое» решение? Вроде есть ОС и ей можно по разному пользоваться. Только пару программ установить, заточить немного под себя…

      Android, на мой взгляд, законченное решение.
      • 0
        Я не хочу уменьшить ваши заслуги: это круто и достойно уважения. Но пока нет полностью «законченных» решений в моём представлении, я буду упиваться фаном от разработки своей «половинчатости», но использовать её по полной, а не треть вашего решения.
        Удачи вам! (А лучше успехов) Надеюсь, что когда-нибудь я решу использовать именно ваше решение (лёгкость внедрения перевесит фан от прогинга)

        Часто сам путь и является целью. Как и у многих из нас.
        Я не сам разработал систему. Одному такое не осилить. Я подсел к другому и вместе мы смогли хоть что то сделать.

        P.S. а жена то смирилась?

        Я свёл всё взаимодействие жены и дома к минимуму. :) Самое главное, чтоб дверь по брелку открывалась. Что б локально можно было включить свет.
        Я не присылаю ей десятки email в день с сообщениями (только если кто-то звонит в дверь) и так как расходы на систему прекратились, то и проблем больше нет.

        Ну иногда, конечно происходят недопонимания. Последний раз был вопрос: почему батарея отопления в ванной не нагревается, хотя я кнопку рядом нажала?.. Все перепроверил и выяснил, что ТЭЦ отключила отопление (это в июле то). Виноват не дом, но, как говорится, а осадочек то остался. :)
        • 0
          А у меня сосед отказывается от пульта и упрямо использует выключатели, которые оставлены для экстренного отключения устройств (тупо отрубает электричество)
          • +3
            Это значит, система не очень продумана. Выключатели на стенках должны работать как обычно (в идеале должно быть возможно выключить прибор выключателем и включить с пульта и наоборот)
      • 0
        Ну Android возможно пример не очень удачный.
        Я имел в виду, что я не могу взять «купить» Андроид и использовать его.
        Мне нужны некие навыки, чтобы подогнать его под железо и всё такое…
        А вот винда уже более «законченное» решение. Её можно поставить почти без навыков на большинство решений.
        • +2
          Ну что ж. Нет предела совершенству.
          The Thing Sytsmes пошли дальше, они при установке софта сканируют дом и систему (dlna, MQTT) на наличие устройств и автоматически их интегрируют. И мы так сделаем. Но это ребята с полным рабочим днём, а я ещё и поспать иногда хочу. :)
  • +3
    Реально быстрее просто ткнуть в кнопку. Кроме того, в современном мире, где работа в основном сидячая, наоборот думаешь о том как бы выполнять больше действий. Сильно напомнило мультик «Нехочуха»
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Я бы вот хотел, чтобы Ардуино мог «из коробки» общаться с мультиваркой, но дьявол кроется в деталях: мне нужно искать библиотеку для передатчика, библиотеку для протокола, внедрять в общий код, обновлять GUI.
      Может у меня получится сделать мега крутую и удобную систему, но вот нарисовать красивый GUI я не в силах.
      CCU.IO это такая штука, которая поможет вам работать со всеми датчиками/устройствами без лишней мороки и снабдит вас красивым интерфейсом. «Умность» (логику) вам предстоит программировать самому. Посмотрите пункт Script Engine.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          В чём то я с вами согласен
          habrahabr.ru/post/227435/?reply_to=7778551#comment_7778497
        • 0
          Да насчет драйвера в 100 срок, это вы правы. Ошибки учтены и сейчас пишем обновление, но прежде чем что-то появится, пройдет пол-года.

          Это сервер, который принимает подключения, от ограниченного набора датчиков, по заранее заготовленным параметрам, и как я понял, оно воспринимает только ON\OFF
          Воспринимает любые данные. Строковые, логические, целочисленные и с плавающей запятой. Ну и если очень надо, то объекты и массивы, только вот элементы визуализации не умеют с ними (объектами и массивами) работать.

          Я склоняюсь к тому, что каждый «умный дом» уникальный, и единое законченное решение сделать невозможно, кроме разве что примитивных датчиков света\температуры и замков.

          Да согласен. Дом слишком индивидуален, что б принести домой коробочку и всё. Но облегчить работу можно.
    • +14
      Я не стал очередной раз описывать, что отопление, свет и жалюзи и у меня управляются автоматически, т.к. это описано в прошлой статье и сосредоточился на дейстиветельно новых вещах. Но уж если до того дошло, то перечислю:
      — Жалюзи открываются в 6:45 по будним дням и в 8:30 по выходным, причем в детской в 9:30
      — Закрываются, когда датчик освещения показывает вечер.
      — Если температура на улице выше 30° и ещё не вечер. то закрыть жалюзи со стороны где солнце и открыть их вечером, когда жара спадет (после 19:00)
      — Если ни кого нет дома, то сбросить отопление до 18° и обогревать, если кто зашел.
      — Мониторить присутствие людей дома: по IP телефона, по датчику движения, по открытой входной двери.
      — Сообщать голосом при уходе из дома (если нажата кнопка: «все ушли»), что окна не закрыты.
      — Мониторить открытую дверь дольше, чем Х минут и присылать фото на почту при каждом открытии двери (Я могу позвонить соседям, что бы они закрыли)
      — Вечером по датчику движения включать в коридоре свет на полную, а ночью только слабую подсветку.
      — Выключать в 1:00 весь свет дома в комнатах, где нет движения (мы часто не выключаем свет вечером сами, зная, что он выключится)
      — Присылать сообщения обо всех событиях (датчики окон и двери), если никого нет дома.
      — При открытии окна в любой комнате дольше, чем на минуту, останавливается отопление в этой комнате и включается обратно при закрытии

      Если это не умный дом, то что тогда это?

      2) не увидел, ничего «умного». Видя датчики температуры в каждой комнате, поневоле вспоминается буханка хлеба и троллейбус.

      А как ещё можно организовать отопление индивидуально в каждой комнате? У нас просчитывается сколько тепла зашло в квартиру и сколько ушло и за разницу температур я плачу деньги. Так что каждый ватт на счету.

      3) исходя из второго, а как ваш CCU.IO решает проблему выключения кондиционера, если температура опустилась ниже 25 градусов, в окно светит солнце, а дома только жена? как по мне — это есть автоматизация, а не датчики и выключатели света

      Если бы был кондиционер, то он бы управлялся через IR Lirc.

      Больше интересна ваша аппаратная реализация, передачи данных, проводные, беспроводные. А алгоритмы и ГУЙ — это уже дело десятое.

      Про аппаратную реализацию, я уже писал в прошлой статье довольно подробно.
  • 0
    Простите, но с подобными системами не доводилось сталкиваться, поэтому извините за возможно глупые вопросы. Стало интересно, как устроена архитектура связи с датчиками. Я так понимаю нода у вас выступает клиентом для некого софта `HomeMatic`. A `HomeMatic` — это соответственно вендорный софт для управления датчиками и чтением их параметров и нода общается с ним через `http` протокол. Я правильно понимаю? Или `HomeMatic` это микроконтроллер с датчиками и веб сервером для управления на борту. Как настраиваются/подключаются датчики к `HomeMatic`; он поддерживает только датчики определённого типа?
    Подытожу вопрос: Как и какие датчики подключаются и каким образом они управляются из под nodejs? Спасибо.
    • 0
      HomeMatic это всего лишь исполнительная часть. Она может быть любая. Если действительно интересно почитать про HM то вот здесь:
      habrahabr.ru/post/149716/
      www.megasensor.com/gotovye-resheniya/avtomatizaciya-zdanij/sistema-umnyj-dom-HomeMatic

      Но, как я уже писал, статья не о железной составляющей. Это слава богу уже не проблема. (Z-Wave, HomeMatic, KNX, NooLite, FS20, ...) решают эту проблему на ура.
      • 0
        Ага. Теперь понятно почему так много скриншотов с немецким языком.
      • 0
        Спасибо, понял, нода подключается к этой «исполнительной части» и запись/чтение производит по http транспорту. Пробежав код по диагонале, настоятельно рекомендую отрефакторить приложение. Используйте es6 — код станет чище. И с архитектурой немного беда, даже вот те же адаптеры — здесь можно действительно сам паттерн `Adapter` использовать, а не только само название. Работа с сокетом и вся другая техническая логика должна быть вынесена в базовый класс, скажем `Source` с однотипным интерфейсом. Дальше расширяем его на `CcuSource`, `HttpSource` и т.д. А потом уже адаптеры наследуются от нужного типа и реализуют абстрактные методы. В идеале gismeteo адаптер должен состоять лишь из определения каналов и метода который трансформирует полученные данные. И более того, хороший AdapterProvider следует парадигме `convention over configuration`.
        А так отличный проект, на этом желаю вам успехов!
        • 0
          Отличный совет. Постараемся перенять по возможности. Спасибо.
  • 0
    Громадный респект за качественно проделанную гигантскую работу!
  • +15
    Очередной умный дом ради умного дома. Пока что для меня самый яркий пример одного из аттрибутов умного дома — термостатический смеситель. Были проблемы — долгая настройка температуры воды, возможность обжечься, нестабильная температура. Теперь их нет. Я просто высталяю температуру и моюсь. Но это, наверно, не IT и не модно. Модно было бы, наверно, выставлять температуру на iPhone, чтобы он через облако связывался с RaspberryPi, который, в свою очередь, посылал сигнал Arduino, который через сервопривод крутил бы кран.

    Извините, просто больно смотреть на сегодняшний прогресс. Кажется, что в 200x году что-то пошло не так. Люди перестали решать задачи, и делают странные решения ради самих решений, а другие их воспевают.
    • +2
      В развитых странах (США, Европа) решения для умных домов есть уже более 30 лет и они работают, но цена на эти решения очень высока. Поэтому сейчас многие пытаются придумать свой велосипед, удобный и доступный всем и выйти на рынок, не у всех это конечно получается, но то что прогресс есть — это уже явный плюс.

      Пример: Неделю назад я зашел в строительный магазин Касторама, кое что нужно было купить, случайно забрел в отдел сад-огород где продают разного рода поливалки, посмотрел, пощупал, цены конечно кусачие. Через пару дней дома щелкая теликом увидел фильм Бетховен (внимание! фильм снят в 1992 году, то есть 22 года назад) и там я увидел что газон поливает распылитель который у нас в России в продаже появился буквально лет 5 назад, я такой увидел в магазине только этим летом.
      Вот теперь подумайте насколько мы отстали от запада. А что говорить про системы автоматизации дома, если бональный разбрызгиватель у нас на рынке появляется через 15 лет.

      Мы в глубокой жо… е по поводу автоматизации домов и то что сейчас делаются попытки выйти из неё — это очень радует.
    • 0
      Я тоже думаю сейчас над конструкцией смесителя, хочу сделать его на ардуине. Вы свои наработки никуда не выкладывали?
  • +1
    Можно добавить еще несколько опенсорсных систем домашней автоматизации:

    Freedomotic — новое опенсорсное программное обеспечение для автоматизации дома, распространяемое под лицензией GPL2, написанное на Java (что позволяет запускать его на Linux, Mac или Windows). Основная задача ПО — предоставить энтузиастам возможность самостоятельно создать систему умного дома, объединив самодельное оборудование или используя для этого готовые решения популярных архитектур. Также Freedomotic позволяет интегрировать умный дом с социальными сетями, интернет-сервисами и сторонними приложениями посредством развитого API.

    Agocontrol — www.agocontrol.com/

    Ninja Blocks — shop.ninjablocks.com/pages/open-source

    Domoticz — www.domoticz.com/

    Вроде все из них активно развиваются, так что выбор всегда есть и это хорошо!
    • 0
      Долго вспоминал, и наконец, утром вспомнил. Есть ещё The Thing System (http://thethingsystem.com/). Отлично подходит для автоматизации, но нет визуализации.
    • 0
      Добавил в статью. Спасибо.
    • 0
      Domoticz кстати на плюсах написан, а не на C#. И внутри там ужас.
  • 0
    MIT лицензия разьве предусматривает ограничения на комерческое использование?
    • 0
      Там есть части под CC NC BY. (Creative Common, Non commercial)
  • 0
    Респект автору, проект очень интересный! Но возник вопрос (возможно, по невнимательности): можно ли к системе подключать «нативные» драйверы (написанные на Си/С++ под хост-платформу)?
    • 0
      Из nodeJS можно вызывать любой бинарник и принимать выходные данные. Так например работает драйвер Ping. Либо же бинарник предоставляет TCP / IP интерфейс и тогда его без проблем можно подключить к системе.
  • +2
    У меня нет умного дома, я снимаю квартиру и часто переезжаю. Но про умный дом всякий раз задумываюсь. Есть ли реализации переносимых умных домов? Который можно за пол часа собрать в коробку, увезти в новую квартиру и за пол часа развернуть систему? Такой умный дом я бы хотел использовать.
    • 0
      Который можно за пол часа собрать в коробку, увезти в новую квартиру и за пол часа развернуть систему?


      За пол часа можно разве что датчик температуры/влажности/задымленности/открытости-закрытости окон-дверей прикрутить. То есть то что легко лепиться на скотч и при этом не нужна отвертка. Все остальное же нуждается в установке с помощью как минимум отвертки, даже такая простая система управления светом как Ноолайт.

      Но датчики бесполезны без конечных испольнительных устройств, а без них это уже не умный дом, а простой сбор информации. А что с этой информацией Вы будите делать — не понятно.
      • 0
        Понимайте «пол часа» в переносном смысле. Другими словами: оптимально быстро. Понятно, что функциональность такой системы будет ограничена, и все же, это лучше чем ничего.
        • 0
          Тогда набор датчиков, пультов и силовых блоков Ноолайт. Если все изначально настроено, то установить их можно достаточно быстро. Единственное что портебуется для установки силовых блоков — это установить их на люстру (под люстру), это делается тоже довольно быстро, у меня это занимает максимум 5 минут на 1 люстру.
  • +7
    У меня взгляд немножко субъективный, так как я много лет работаю в области промышленной автоматики и машинного зрения, но тем не менее. Вообще если разобраться, то «умный дом» — это просто классическая задача автоматизации. Есть набор датчиков (температура, влажность, ветер, контакты дверей и окон, свет, детекторы движения и т.д.), набор исполнительных механизмов (жалюзи, термостаты, освещение, и т.п.), шина, которая их все соединяет, контроллер, который всем этим управляет, ну и визуализация, конечно — СКАДА, иными словами. Степень «умности» дома у всех разная — кто-то просто ставит датчики температуры в каждой комнате и на андроид планшете это дело визуализирует и объявляет это «умным домом», кто-то идёт дальше. Полностью умный (в футуристическом смысле) дом, к сожалению построить не позволяет современное развитие технологий и инфраструктуры. Я имею ввиду дом, который сам вам приготовит завтрак (по выбору дома), уберёт посуду и закажет продукты, которые магическим образом переместятся в умный холодильник, постирает и погладит бельё, и т.д. — ну типа умного дома у шерифа в сериале «Эврика» Это дело далёкого будущего (но, надеюсь мои внуки или правнуки будут жить именно в таком).

    Есть ещё один аспект — это стоимость. Это прежде всего бытовое использование и применение промышленных наработок тут будет неоправданным. ОК, у меня есть возможность получить на работе списанные ПЛК и модули, которые практически идеально подходят для автоматизации (хотя и не идеально для домашней). Сейчас у меня стоит GE Fanuc и СКАДА написана на LabVIEW, а коллега автоматизировал всё и вся на Сименсе, но стоимость одного такого контроллера приближается к стоимости хорошего автомобиля, что для дома неприемлемо (да и ПО для разработки отнюдь недешёвое). Отсюда рождается огромное количество решений на Ардуино или «малинках», которые делают то же самое, но стоят на порядок меньше.

    Энергопотребление — тоже важный параметр. С ростом количества устройств растёт энергопотребление. В моём случае контроллер прожорлив сам по себе, плюс компьютер, на котором крутится скада, плюс камеры и т.д… — и в результате мне это удовольствие вылилось в 600 евро в год только по электричеству. Теперь дом поумнел и старается сам экономить, отключая устройства, которые ему не нужны, но в общем он потребляет больше чем экономит.

    Ещё один аспект — это интеграция в существующий дом. Если все розетки, выключатели и т.п. уже проложены и сделана чистовая отделка, то не каждый начнёт штробить стены для прокладки новых кабелей — это имеет смысл делать на этапе строительства. Я вот давно хочу сделать автоматические жалюзи, но раздолбить полкомнаты, чтобы проложить силовые кабели к моторам пока руки не поднимаются. Мой коллега сделал умный дом при постройке — и у него ушло около восьми километров кабелей на всё про всё (он KNX использовал c Eisbär).

    Резюмируя — пока что «умные дома» — это, как мне кажется, больше для гиков, которые что-то могут сделать сами с той или иной степенью «наколенности» и «умности». Об этом опять-же говорит явный перекос в сторону веб-технологий — там PHP, JS всякие и иже с ними — в промышленной автоматизации я себе такое даже представить не могу, так что в ближайшем будущем мы увидим ещё немало статей «как я включил свет с планшета».

    Вообще как мне кажется (возможно я и ошибаюсь) — сейчас самое время мутить стартапы, которые будут автоматизировать дома для «богатеньтких буратино». Я вижу на рынке большое количество устройств для автоматизации, а вот интеграторов, делающих «под ключ» — что то не очень (тех, кто не только ПО предоставит, но и стены продолбит, и всё настроит, подключит и предоставит сервисное обслуживание).
    • +1
      так как я много лет работаю в области промышленной автоматики

      Я из этой же области. И в данный момент просто упиваюсь возможность писать правила на Js, PHP и т.д. Не могу себе представить, что нужно использовать S7-300, пожирающую 50 Вт и SIMATIC.NET или TIA Portal или доисторический WinCC. И писать программы на AWL, SCL.
      Именно область домашней автоматизации позволяет делать здесь допущения, что если что-то пойдет не так, то корабль или конвеер не встанет и 1000 людей не будут рассержено ждать у пропускного пункта, только из за того, что контроллер решил сделать перекур.
      И в обратную сторону, я только в страшном сне могу представить управление газовой турбиной по arduino или на малине, пусть даже у нее больше производительность:)
      Для каждой задачи свои инструменты.

      • 0
        Кстати, из за меня уже задерживали открытие аэропорта (система доставки чемоданов) и совсем недавно (слава богу, не только из-за меня) отложили на пол-года сдачу лайнера на 3000 человек. Ощущения не из приятных. Хоть там и S7-400 по 40килоевров пара и софта ещё на столько же, однако с пол пинка не завелось.
        Так что да здравствует: 2 пользователя, JS и всего 100 устройств. :)
      • 0
        А я наоборот, хотел бы видеть, например имплементацию LAD для умного дома для наглядного использования блоков И-ИЛИ-НЕ и таймеров и т.д :)
        Еще у меня вопрос насчет «быстродействия»: например, какая-то кнопка в системе может быть нажата быстро, либо датчик сработает (выдаст короткий импульс) слишком быстро, а опрос настроен, например, раз в секунду — можно и потерять нажатие!
        Или двойной клик по выключателю?..
  • 0
    Вопрос.
    Наконец появилась своя квартира. Начинается стадия постепенного ремонта (сначала одну комнату, потом может другую).
    Сейчас первой на очереди детская. Ваша статья родила мысль — почему бы сейчас не заложить в стены некие датчики (например для 1-wire), чтобы потом можно было задействовать в умном доме (которые вероятно буду затевать, в том или ином виде).
    То есть вопрос вот какой — что имеет смысл закладывать сейчас в виде например трасс связи и датчиков, для дальнейшего использование в системе типа «умный дом»?
    Спасибо
    • +1
      Я планирую в качестве транспорта использовать LAN кабель 5е категории. Все равно локальную сеть тянуть. А так можно будет некоторые точки входа распотрошить на жилы для датчиков и исполнителей. Все собирать на патч-панели в одном месте, где магистральный роутер и свитч.
      • 0
        А питание таким датчикам как подавать? Не имеет ли смысл предусмотреть подсветку по полу? Датчики движения возле двери, чтобы двери не переделывать потом?
        • 0
          Питание по тем же проводам. PoE называется.
  • 0
    На самом деле концепция умного дома очень актуальна для людей, страдающих разного рода расстройствами памяти. В России эта проблема более актуальна, чем за рубежом, потому что в тех же США отправлять стариков дома престарелых — это нормально, а у нас — это считается нехорошим поступком со стороны детей. Поэтому дети либо берут к себе престарелых родителей, либо приезжают к ним помогать по дому. А очень много можно было бы делать в онлайне.
    Можно сказать, что это — подсказка для организации реального бизнеса :)

    Что касается существа вопроса, то хотелось бы понять всё-таки, как соотносится полученная экономия от выключения лампочек (особенно если это светодиоды по 7-10 вт) и прочего оборудования со стоимостью управляющего оборудования и затратами на его эксплуатацию (электричество, человеко-часы на настройку)… Просто хоть какая-то статистика?
    • 0
      Делали автоматизацию для слепого человека (Управление голосом). Но опыт был негативным. Да всё заработало, но клиент оказался очень привередливым… Хотя, наверно, не привередливый клиент редкость. :)
      • 0
        Согласен, инвалиды вообще своеобразно воспринимают мир. Но здесь потенциальная клиентская аудитория — это не сами пользователи, а их близкие, которые таким образом покупают не услуги для себя, а своё спокойствие за родных.
  • 0
    Сообщаю в комментах. Система на стадии разработки. Голова на Raspberry Pi. PERL+JavaScript+JQuery. Датчики беспроводные NRF24L01. Протокол самописный с шифрованием XXTEA и обменом одноразового ключа (паранойя прогрессирует). Датчики/исполнители на msp430 и atmega
    • 0
      У меня был интересный случай: дочери на пятилетие подарили сертификат на катание на лошади. И вот дарители рассказывают, как это классно, какие там лошадки и пони. Ребёнок слушал, слушал и спрашивает: А где лошадь то!?

      Так вот и я. А где код то? :) Дайте посмотреть. :)
      • 0
        что именно интересует? фрагменты кода датчиков/исполнителей могу показать. Общая концепция вроде устаканилась, но допиливается по-ходу пьесы. Повторюсь, система на стадии разработки.
        • 0
          Интересует архитектура и GUI. Так как написано JQuery, могу сделать вывод, что GUI есть.
          А как на PERL обрабатывать socket соединения и постоянно их поддерживать?
          • 0
            сознАюсь, ГУЯ в ближайших планах. с Вами кстати недавно беседовал по-поводу визуальных конструкторов скриптов автоматизации. Жалился на немецкий.
            А по-поводу перла — не сложно. у меня RPi общается через uart с дополнительным контроллером, на котором висит пара nrf-ок. PERL использует библиотеку Device::SerialPort. Но если нужно сокет поднять, то есть IO::Socket. Можно форкаться при получении пакета для обработки, если большая нагрузка.
            • +1
              Кстати, ScriptGUI перевели на 90%. Так что там сейчас почти всё по русски и по английски.
              • 0
                это есть гут!
    • +1
      паранойя прогрессирует
      Если бы она действительно прогрессировала, вы бы в сторону любой беспроводки даже не взглянули. Получение доступа еще не вся проблема.
      • +1
        ну на текущий момент XXTEA не разломан пока еще, если верить интернетам. А так, для тренировки решил поковырять шифрование. Потом, если система не распространена широко, считаю довольно сложно с 0 её взломать.
        • 0
          Зачем ее ломать?
          Знаете как спички в замочную скважину вставляют? Это же делают не для того, чтобы войти…
          • 0
            согласен, можно и помеху поставить.
            критические вещи, типа открыть входной замок — можно проводами сделать.
            • 0
              Я подозреваю, что вместо решения этой проблемы будут использовать всякого рода костыли типа ППРЧ по нелицензируемому диапазону, но этого тоже не на долго хватит если заняться.
              • 0
                ну тут главное вовремя остановиться. ППРЧ можно сделать и средствами NRF-ки(128 каналов, правда диапазон 2.4ГГц), но надо ли. Думал сделать сканер диапазона периодический с целью выбора наименее загруженных частот, но это уже совсем когда будет нечего делать.
  • 0
    Пришёл к выводу, что самый удобный для меня вариант это vera в связке с arduino. Vera в качестве головы, arduino nano в качестве шлюза между vera и на бором беспроводных датчиков на базе arduino+nrf24l01. Впринцепи на этом и остановился бы, но vera дорога стоит и есть малина без дела. Поэтому нужна ось которая становится без проблема на малину и можно без бубнов приделать arduino gateway. Если ССUI это может то хотелось бы увидеть пост на эту тему. СПС.
    • 0
      Что то я не нашел у Веры европейских розеток. Наверно туда можно подключать и другие Z-wave приборы, а если это так, то Vera Controller не нужен. Эту роль может исполнять и малина с USB стиком и openzwave на борту.
      С другими системами, тут такое дело: что б их встраивать, нужно железо, а железо стоит денег, а проект опенсурсный… Я вот недавно купил набор юного z-вейвера (набор датчиков и свисток). Ну просто потратил своих денег на 200 евро. Товарищ купил KNX железа на 300 евро… Но все системы не скупишь. Вот тут то и нужна помощь commnity, что бы реализовали драйвера под всё что подключается… А без коммьюнити тяжело. :(
      • 0
        я поначалу тоже z-wavом был ахмурен, а потом когда начал разбираться в этом железе, понял что это просто протокол обмена информации и всё это понты. А vera рассматривал просто как мозги, и коробочка красивая)
  • +3
    Не хватает варианта ответа «У меня нет своего дома, но хотелось бы»
  • 0
    Срочно нужна интеграция с ПЛК по Modbus TCP !;)
    • 0
      Сейчас коллега рассматривает вариант получения данных из S7-400 в CCU.IO.

      Какой use-case у вас?
      • 0
        Либо ПЛК S7-1200, либо модули ввода-вывода на RS485 Modbus RTU…
  • 0
    Перечислите, пожалуйста, в отдельном комментарии все фукнции (сценарии) вашей системы.
    Интересует, как вы реализовали «стирка окончена»?
    • 0
      Также интересует, как реализовали голосовое управление, точнее как этот модуль выглядит в системе.
    • 0
      Есть модуль, который мониторит расход энергии:
      www.elv.de/homematic-funk-schaltaktor-1fach-mit-leistungsmessung-zwischenstecker.html
      Я получаю сообщения о расходе энергии. Если расход 0.1 W, то машина работает, если расход в течении 3 мин < 0.1, то стирка закончилась.

      Есть несколько решений: можно подцепить датчик на лампочку, но для этого надо разбирать машинку. Можно использовать реле:
      image
      Но оно стоит столько же, сколько мой модуль.

      Я уже описал в комментариях: habrahabr.ru/post/227435/#comment_7779015
      могу только добавить:
      — включать усилитель, если SONOS проигрывает музыку и выключать, если не проигрывает дольше 3 минут.
      — при нажатии на кнопку звонка 3 раза подряд с определенным интервалом, открыть подъездную дверь.
  • 0
    Ни в коем случае не умаляю достоинств описанной системы — работа проделана огромная и результат впечатляет. Нельзя ли немного подробнее про вот это:
    — MajorDoMo — визуализация и автоматизация. Недостатки: PHP и polling событий. Нет возможности писать сложные драйвера, т.к. нет таймера. Cron не в счет.

    PHP это недостаток в принципе?
    Насчёт «нет возможности» тоже не очень понятно… Что значит нет таймера? Почему только polling событий? Не хотелось бы вводить народ в заблуждение, поэтому, если объясните, что именно имеете в виду, то я смогу либо это подтвердить, либо опровергнуть, а то как-то однобоко выходит.
    • 0
      Вообще-то я надеялся, что такое заявление придёт намного раньше (ещё вчера) и даже хотел написать рядом, что это Холивар и давайте не будем. :)
      Я убрал из статьи слово «недостатки» и объясню, что я имел ввиду:
      — «polling событий» означает, что новые события на GUI опрашиваются с интервалом 5 секунд
      eventTimer=window.setTimeout ('getNextEvent();', 5000);
      

      Это означает, что между событием и его отображением на экране может пройти до 5 секунд.
      Node.JS использует socket.io задержка между событием и отображением около 100-200 ms.
      — писать сложные драйвера:
      PHP is not meant to be run for extended amounts of time. Many will argue with me here, but the language by default is set to terminate itself once it has been running for 30 seconds, or if it reaches a certain amount of memory usage. This can be disabled, and apps can be built to run for a long time successfully, but this is not where PHP shines.

      Выборка с https://thomashunter.name/blog/php-vs-nodejs/
      Да конечно, можно и микроскопом гвозди забивать… Но зачем?
      • 0
        Насчёт «polling» согласен в части GUI — действительно ряд вещей запрашивается интервально, но приведённый выше пример немного некорректен, т.к. в системе не один механизм создания GUI и пример взят из наименее используемого и наиболее медленного. Но не суть — в главном я согласен, что socket.io лучше, чем polling. Только ещё одно важное замечание — всё это касается интерфейса, т.к. реакция на оборудование идёт по событийной модели (кроме тех случаев, когда оборудование это не поддерживает), т.е. без опросов вовсе. Ну и до кучи — таймеры там присутствую и активно используются (без участия cron-а).

        Насчёт PHP vs Node.JS — это действительно холивар и я знаю аргументы по-лучше (в пользу Node.JS), но пока не сталкивался с тем, что PHP, как инструмент, не позволял реализовать то, что мне нужно или делал это как-то хуже.
        • 0
          т.е. без опросов вовсе. Ну и до кучи — таймеры там присутствую и активно используются (без участия cron-а).

          Это я уже тоже выяснил. :)
  • 0
    Не хватает примеров использования.
    Хотя может не там рою.

    У меня задачка простая собрать показания термодатчиков с 1-wire и отобразить из на web морде. Возможно с графиками.
    Ну и в последствии подключить управление насосом отопления.

    Кстати, кто подскажет безпроводное исполнительное реле для выключения насоса?
    • 0
      1-wire можно подключать по OWFS (One-Wire-File-System).
      Здесь есть человек, который попытался подключить OWFS.
      forum.iobroker.com/viewtopic.php?f=6&t=14
      Можно его спосить, как далеко он продвинулся.
  • +1
    «Потыкал» DASH UI — Круто!
    голосом из старкрафта: «Необходимо больше мануалов» — давайте мануалы «шаг за шагом создаем виджеты» или вообще «шаг за шагом строим умный дом» — как создаются каналы, виджеты и т.д. и т.п!
    Очень неплохо!
    • 0
      Для Модбас есть библиотека NBodbus, написанная для .NET от компании ICPDAS — у них на FTP серверах есть. Это я так, на всякий случай)
      • 0
        А ModBus over TCP IP или через Com Port?
        • 0
          RTU наверное, лучше. Чем? — Тем, что модули дешевле))
          Много производителей пром. оборудования ( у того же овена — много недорогих модулей, в китае — еще дешевле) выпускают модули входов-выходов на Modbus RTU. Есть как модули цифрового, так и аналогового ввода-вывода.
  • 0
    Было бы хорошо добавить в список систем вот эту ссылку: github.com/maros/Homely. В статью и вот в этот блог: hobbyquaker.blogspot.de/2014/09/smart-home-software.html
    Марош довольно активный член Perl комьюнити. (Homely, GPLv2, Perl, Vera, Z-Wave, RazBerry )

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