HomeKit

[sergejey]

К сожалению, анонса о том, что система поддерживает HomeKit пока не будет. Приглашаю к обсуждению вариантов интеграции.

Предыстория -- HomeKit это стандарт (протокол) обмена информацией между устройствами о своих возможностях. Инициатором этого протокола является компания Apple. Базовый вариант использования -- продукты Apple (телефон, часы, siri) с помощью этого протокола могут находить совместимые устройства в локальной сети и сразу научиться ими управлять. На самом деле, устройства по этому протоколу сообщают что они такое, где находятся и что умеют делать.

Хотелось бы, чтобы при наличии в сети системы MajorDoMo, устройства от Apple сразу находили то, чем они могут управлять.

Есть две сложности. Первая -- реализовать поддержку этого протокола на техническом уровне. Документация крайне эпизодическая и, честно говоря, я не смог найти чёткого описания сеанса обмена данными. Если кто подскажет, где эту документацию найти или какой открытый проект можно "расковырять", что бы эту информацию получить, то буду весьма признателен. Есть открытый проект HomeBridge и, теоретически, можно к нему написать плагин для MajorDoMo, но он сам по себе должен быть отдельно установлен -- не хотелось бы это на пользователя перекладывать. Но может быть это и неплохой вариант -- можно подумать, обсудить.

Вторая сложность -- структура самой системы MajorDoMo. У нас нет простого понятия "Устройства". Т.е. их может быть множество разных, на разных протоколах и т.п. Объединяющим "клеем" являются объекты и классы -- в рамках организации внутренней логики всё здорово, но не для того, чтобы обеспечить что-то вроде выгрузки всех устройств и их возможностей. Здесь надо придумать какой-то механизм "упрощения". Например, считать, что все объекты у которых есть метод Switch являются выключателями и тогда мы сможем через Homekit выдать все выключатели, причём даже с информацией о том, где они находятся (возможность привязки объектов к комнатам у нас уже есть, хоть и используется только для фильтрации списков).

В общем, буду рад комментариям на эту тему.

[Alien]

Я не особо крупный специалист, но считаю что нужно начинать именно со второго вопроса. Первый - частность и, к сожалению, привязанная к проприетарному ПО и железу. Решив второй вопрос уже можно будет подвязывать яблоки, гнусмусы и прочий закрытый и открытый зоопарк.
По части второго вопроса, думаю, в основном большинство приблизительно по этому пути и шло. По крайней мере я разделял функционал датчиков, исполнительных устройств и т.д., указывая между ними связи. Так что выработав общую стратегию нужно просто внести соответствующие правки в классы исходной базы и все последователи уже будут исходя из нее идти по верному пути.
Может сумбурно, но приблизительно это я имею в виду:
1. Железо, к примеру, датчик температуры mysensors. Собирает данные у шлет их в связанный объект класса датчики.
2. Класс датчики собирает информацию, обрабатывает ее корректность, проверяет на доступность и т.д. К нему привязана соответствующая комната/зона.
3. Комната/зона уже собирая информацию с привязанных датчиков и имея в свойствах желаемые параметры отдает команды связанным с ней HVAC, свету и мало-ли каким еще исполнителям.
4. Исполнительные устройства контролируют самое себя, получая распоряжения от класса комнат/зон и состояний системы.
Ну, где-то так, если я правильно понимаю суть вопроса.

[sergejey]

Может сумбурно, но приблизительно это я имею в виду:
1. Железо, к примеру, датчик температуры mysensors. Собирает данные у шлет их в связанный объект класса датчики.
2. Класс датчики собирает информацию, обрабатывает ее корректность, проверяет на доступность и т.д. К нему привязана соответствующая комната/зона.
3. Комната/зона уже собирая информацию с привязанных датчиков и имея в свойствах желаемые параметры отдает команды связанным с ней HVAC, свету и мало-ли каким еще исполнителям.
4. Исполнительные устройства контролируют самое себя, получая распоряжения от класса комнат/зон и состояний системы.
Ну, где-то так, если я правильно понимаю суть вопроса.

Да, всё верно. Приблизительно по такой схеме у меня дома так и построено: физическое устройство -> объект сенсора -> объект комнаты с показаниями, из которых идёт управление. Т.е. можно менять устройства на физическом уровне, сохраняя объект и даже на логическом уровне меняя объекты, отвечающие за показания комнат. Но последний уровень в контексте задачи уже не так актуален, т.к. тот же Homekit работает на уровне конкретных сенсоров/исполнителей.

[Alien]

Не знаю как правильно сформулировать мысль, но вижу вопрос в некоей двойственности сути объектов.
С одной стороны, с точки зрения программирования системы, Switch это и чайник, и лампочка, и ворота гаража. Или Dimmer - может быть и лампочка, и штора, и контур отопления.
С другой стороны, для удобства просмотра и неискушенного нувориша, чайники и ворота в одном классе - головоломка. Потому каждый сам для себя решает как создавать классы и связывать устройства с модулями.
Возможно правильным костылем был бы, так сказать, модуль "по связям с общественностью". Я имею в виду встроенный стандартный модуль, включающий в себя некий стандартизированный протокол для общения с внешним миром (устройствами от любых производителей) с четким описанием классов сенсоров и исполнителей. В свою очередь авторы модулей для конкретных устройств общались бы с МД не непосредственно через базу, а через этот модуль. Наверное путанная мысль...
Ну вот, к примеру, модуль mysensors сам связывает полученные данные со свойствами конкретных устройств в конкретных классах, созданных пользователем. А можно чтобы модуль mysensors лишь отвечал бы за обработку одноименного протокола и отдавал в стандартизированном виде данные модулю "по связям с общественностью". Тот, в свою очередь, агрегировал бы эти данные и предоставлял их желаемым пользователю объектам. То есть при таком модуле пользователь, создавая, объект мог бы выбрать его тип (switch, dimmer и т.д.) и получить требуемые свойства и методы, при этом расположив свой чайник в классе чайников, а не переключателей.
Это подвело бы МД к настройке через GUI, а не методом программирования: перетащил кнопку из пула в желаемый класс, назвал ее чайником, в свойствах выбрал имеющееся в модуле "по связям с общественностью" устройство и насладился работой, не переживая за протокол общения конкретного чайника с МД - лишь бы модуль соответствующий был разработан. И в обратную сторону, если есть модуль с протоколом, конечно: включился чайник, объявил себя, модуль с протоколом его нашел и сообщил об этом модулю "по связям". А то что это за чайник Apple или Samsung ни пользователю, ни МД знать не обязательно.
Простите за флуд, если лишнее и не в тему.

[olehs]

Использую Homebridge с плагином HTTP. В конфиге прописываются устройства и ссылки на методы в МЖД.

В качестве конфигуратора на iOS выбрал Elgato Eve (хотя и не сильно перебирал)

[nick7zmail]

В плане интеграции (как с homekit так и с дусей той же) мне кажется проще сделать отдельный модуль. Ибо реально - в объектах системы городят все - кто на что горазд. А в модуле сделать как раз структуру, которая будет соответствовать нужному api, формата имя_объекта-функция-связанный метод. А на счет api homekit реально трудно гуглится).
На счет HomeBrige - это вроде открытый проект. Его можно включить, как вспомогательный, в основную поставку...весит не сильно много.

[Vspb]

Вышла ios 10 - может поднять тему? Теперь есть софтина для управления, может больше инфы есть как скрестить?

[olehs]

Как раз обновляюсь))
Софтина и раньше была, просто не родная.
Сейчас как раз и проверю, работает ли оно дальше с HomeBridge

[olehs]

Да, работает как и работало. Приложение Дом подтянуло настройки. Все тоже самое что и в Eve.
Русская Сири не поумнела: чтобы включить свет в гостиной, комната должна называться именно "гостиной"

[Xseon]

Внесу свои 5 копеек...
1. Установил homebridge на сервер с МД под Линукс.
2. Установил homebridge-http
3. Настроил config.json (на 2 света. тв и влажность)

В итоге Ipad c IOS 10 мгновенно увидел свежесозданый bridge. Ввел код. Вуаля, все отображается на Ipad и обновляется по скорости на полсекунды позже самого МД.

Думаю то, что в начале темы имел ввиду Сергей, не приживется в МД ибо МД и так пластелин!
Даже не знаю есть ли практический смысл во всем этом, кроме как поставить/снять с охраны или включить/выключить котел. свет и тд., так как я и так могу из вне зайти на МД и сделать тоже самое. Но все желание отбивает геморой с плагинами для этого самого bridg'a. так как прописать какой-либо датчик, а уж тем более нестандартный целая волокита с остановкой самого демона homebridge!

И даже если брать во внимание тот факт, что сири довольно неплохо распознает речь, то и команды я могу надиктовывать прямо в командную строку сервера МД! Это я уже молчу про сам интерфейс программы "Дом". Штатное приложение IOS пока нервно курит в стороне по сравнению с наглядностью сцен МД!

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