Comments 42
Мои комментарии/пожелания:
— Как всегда больше всего работы вам доставят эти плагины, так как единого стандарта связи с датчиками и устройствами нет. Постарайтесь охватить основные протоколы, а не заморачиваться на экзотике.
— По поводу сценариев — советую не развивать свой язык — их сейчас, наверное, столько же, сколько систем автоматизации, а взять что-то готовое. Например я всем советую движек Node-RED. Подходит для любых сценариев и прост в освоении.
— Настраивайтесь на реал-тайм. С этим во многих системах большая проблема и часто время обработки событий может составлять секунды, что очень критично для таких вещей, как управление светом, например.
— Насчет Windows — в данном софте нужно сразу быть готовым к тому, что он будет крутиться на железе 24/7. А это всякие NASы, или коробочки с пассивным охлаждением. Windows там не очень любят.
— Сразу задумывайтесь о надежности софта, так как это сердце домашней автоматизации. Подумайте о том, чтобы ваш софт работал в каком-нибудь докере, который в свою очередь крутится на нескольких машинах, так чтобы выход из строя одной из машин не приводил к отказу софта.
На счет своего языка — мы и не придумывали его, всё пишется на стандартном JavaScript.
Про Windows — согласен. Уже делаем кросс-платформенную версию.
Остальные замечания — выглядят логичными и по делу, учтем их.
В настоящий момент все такие опенсоурсные системы активно развиваются, в том числе благодаря поддержке пользователей. Т.е. больше пользователей -> больше мейнтенеров -> быстрее появляются новые фичи -> больше пользователей и т.д. В итоге проект, у кого больше коммюнити будет и быстрее развиваться. Вот я и хотел спросить, чем ваш проект отличается от десятков других? Чем вы собираетесь привлекать пользователей?
К сожалению, не знаком со всеми этими решениями.
До этого очень подробно смотрел MajorDoMo. От него мой проект отличается архитектурой и схемой взаимодействия элементов системы.
Могу точно сказать, что от решений на node мое отличается более низкоуровневой платформой (.NET). Это важно, когда нужна производительность или нужно работать с бинарными данными, например.
Также от всех зарубежных систем моя отличается подробной документацией на русском языке.
Вы правы, это всё для разработчика.
Думаю, разработчики — и есть основные пользователи системы. Класс пользователей, которые могли бы настроить под себя какое-либо коробочное решение, кажется еще не сформировался. В основном потому, что не сформировалось четкое понимание, что они хотят автоматизировать.
Есть такие коробки, типа Vera Edge, Samsung Smartthings, Zipato и др. Их может настроить любой, даже не продвинутый пользователь. Проблема в том, что в угоду простоте, там очень мало возможностей настройки, что ограничивает их применение в пределах небольшой квартиры, иначе это просто игрушки.
С другой стороны есть также «полу-коробочные решения», которые можно назвать так — взял железо по выбору, установил одну из систем домашней автоматизации выше, настроил и получил результат.
В обоих случаях я не вижу тут разработчиков. Максимум во втором случае нужны интеграционные способности и немного большие знания компьютеров.
Очень интересная статья и проект!
У самого есть идея разработки похожей системы управления умным домом, с плагинами и скриптами, и так же на .NET (Core), хотя осознаю, что таких решений много — начиная от стандарта де-факта Open Hab и заканчивая упоминаемыми на хабре ioBrocker и вашей системой, почему-то все равно есть, возможно, неправильное, желание делать свой велосипед.
А как устроена изнутри Ваша система?
Я планировал механизм, близкий к ROS (кто знает) — все плагины отдельные процессы, взаимодействуют через сокеты\каналы. В качестве протоколов даже внутрисерверного взаимодействия — MQTT+HTTP (мне кажется, их хватит на все нужды). Плюс — можно подключать стороннее ПО, по MQTT много чего работает. Минус — большие накладные расходы по передачи данных. Так же сервер для хранения данных плагинов и отдельно — настроек (привет, rosparam), настройка через веб-интерфейс и репозиторий плагинов для легкой установки.
Если что-то выйдет — обязательно напишу статью.
Напишите подробнее о своем проекте, очень интересно! Если выложено на github, дайте ссылку на репозиторий, пожалуйста.
К сожалению, от проекта у меня есть только идея и некое подобие написанного для себя ТЗ.
Собственно, идея изначально была не столько программная, сколько аппаратная — сделать очередные устройства на ESP-8266, но размышления привели к тому, что нужно годное ПО сервера, так что проект из двух частей- железячной (сейчас я поглядываю на rtl8710 — аналоги esp) и программной.
Надеюсь, что я все-таки найду время заняться им. Если займусь и получу результат — будет статья.
Скажите смогу ли я написать к нему плагин обслуживания устройства с условиями
— управляющая железка работает по http
— ее можно опрашивать
а) получить температуры с нескольких точек (для диаграммы)
б) режим включен/выключен
в) авторежим включен/выключен
г) минимальная и максимальная температуры (котел работает в их пределах)
— можно менять
а) режим
б) авторежим
в) минимальная и максимальная температуры
со стороны сайта/сервиса нужно организовать по расписанию день недели / час — минимальные и макс темепературы
например
— с 6:00 до 23:00 нужно переключать устройство в мин/макс = 21,2/21,5
— с 23:00 до 5:00 нужно переключать устройство в мин/макс = 19/20
?
Потому что не задолго до релиза АРМ из ожидаемого релиза был вычеркнут. Остался лишь Windows ARM, что не то что я жду.
И пока что я смог нагуглить только то что он ожидается и недавно закрытый ишью: https://github.com/dotnet/core/issues/243
Со ссылкой только на Windows ARM и то для версии 1.2
Я находил еще issue 3977 про количество успешных и упавших тестов на ARM. Там есть комментарий от 15 ноября, что все тесты уже проходят. Думаю, ждать осталось не очень долго.
Лично моя задача номер один это управление отоплением и вентиляцией. Там везде цифровые проводные интерфейсы.
Для управления светом и вентилцией попробуйте эти штуки. Если вашим отоплением можно управлять через реле, то для отопления они тоже подойдут. Это будет удобнее, чем ардуино, т.к. не нужно решать вопросы с корпусом и питанием.
Примеры, как из GUI управлять светом здесь, здесь и здесь.
Готов ответить на любые ваши вопросы.
На это можно было бы и забить, но проблема тут в другом. Кондиционеры от Toshiba умеют управляться пультом не только по ИК каналу, но и по проводному, тогда пульт крепится на стену жестко, не содержит батареек а подключается 3 провода.
Приточные установки тоже имеют свои панели управления, на них выставляется целевая температура, отображаются показания датчиков, выводятся ошибки и также задаются обороты вентиляторов.
К сожалению их протоколы закрыты, их нужно будет реверсить предварительно, т.е. и так полно работы, а протягивать это все аж до ардуино с 0 — вообще не подъемно для воскресного проекта. Что-то типа универсального дву направленного протокола обмена с ардуино, желательно с событиями\прерываниями.
Условно говоря два метода и один ивент. А конструктор принимает айдишник арудино и др параметры связи.
Можно и не ардуино, но без чего-то такого достаточно простого и гибкого — умные дома не взлетят по моему мнению. Максимум будут как конструкторы а-ля сигнализация, купи набор «юный электрик», собери полу-решение.
В любом случае спасибо за ответ.
А так, конечно, с поддержкой более менее plug'n'play устройств пока здесь скудновато. Кроме Noolite и нет ничего. Надо хотя бы добавить Z-wave, Modbus TCP.
А сколько человек пишут систему? А то в начале "я выпустил", а потом "мы писали". Хотя на гите видно, что один человек пишет.
Я всё равно не разделяю желания писать велосипед.
Вы правы, 95% коммитов в гите — мои. Пишу "мы", когда не хочу акцентировать внимание на конкретном человеке.
Про велосипед — не понял.
Подумайте, сколько лет вам нужно будет разрабатывать, чтобы хотя бы поддерживать столько железа?
https://home-assistant.io/components/
Я понимаю, на что мне намекают. Просто странно слышать это от человека, который пишет такой же велосипед.
На счет поддержки железа… Моя основная цель — предоставить качественную платформу. Если платформа будет достаточно качественной и удобной, другие люди смогут легко реализовать поддержку своего железа, как я реализовал поддержку железа, установленного у меня дома.
Сравнивая с другими проектами, я вижу, что мое решение во многих случаях более производительно, легче расширяется, более удобно для разработчика, лучше описано в документации или всё это вместе. Кажется многим людям оно подойдет лучше других (особенно, когда начнет работать под linux).
Кажется, я не очень четко ответил на вопрос...
Я пишу велосипед потому, что в известных решениях меня крайне не устраивает качество платформы. Мой велосипед по качеству платформы значительно превосходит их.
OpenHAB никогда не понимал. Как должно быть: воткнул устройство в сеть — оно само нашлось и начало работать. Для этого в устройстве должен быть тот же протокол, что и в «шлюзе». Java(или CLR)-машину в умную розетку засунуть конечно можно, но крайне нерационально.
Или другой сценарий: не хватает одного шлюза: поставил второй. Они друг друга нашли и стали единым целым
К чему я веду: действительно универсальный протокол «интернета вещей», ИМХО, это прежде всего децентрализованная система, способная автоматически обнаруживать новые элементы и вообще адекватно реагировать на изменение сети. Это маленькое ядро, которое можно воткнуть на самое разнообразное железо. Это протокол, предоставляющий несколько паттернов общения между девайсами (массовое оповещение, бинарный поток данных, публикация/подписка, RPC, итд). Протокол знающий всё о данных, которые он передает (рефлексия API, стандартные и пользовательские профили для устройств, и т д)
«Шлюзы», которые я вижу последние лет 5 — это просто коробочки, в которые можно воткнуть пару протоколов (и конечно же Philips HUE) + приложение на смартфон… И всё. Ни о какой интеграции с другиги решениями речи не идет. Замкнутая на себе система без души. Следующей ступенью «эволюции», видимо будет шлюз, объединяющий все эти шлюзы
а зачем ее туда засовывать, если все, что нужно от розетки — работать с одним из протоколов общения с головой. А на чем написана голова — мало кого волнует.
Сказать, что получилось сложно, это ничего не сказать. Сложный стандарт, сложное ПО, которое работает только на высокопроизводительном железе, даже «умные розетки» и те сложные.
Если начать придумывать что-то такое для Умного дома, то это надо столько времени и сил потратить, что на это дело не хватит ресурсов ни одной коммюнити. Вот и плавает пока каждый в своем пруду.
Не задумывались на развертывании на более компактном железе? Типа Raspberry Pi?
Как у вас реализовано взаимодействие с ethernet-шлюзом Noolite?
Взаимодействие со шлюзом — по HTTP через его API. Код, работающий со шлюзом — здесь.
Не задумывались на развертывании на более компактном железе? Типа Raspberry Pi?
Задумывались. Сейчас пишем новую версию на .NET Core. Она должна работать везде, где работает .NET Core. Насколько я знаю, в ближайшем будущем он будет работать и на Raspberry Pi тоже.
Нужно браться за студию. Готов помочь в этом!
сильная переделка под .Net Core потребуется?
Код на C# при переходе на .NET Core почти всегда нормально работает без изменений, но, если вы используете сторонние библиотеки, они могут не работать.
Кстати, мы пробовали написать 1wire плагин. В результате решили его не включать в список стандартных, т.к. он требовал дополнительной установки сторонних библиотек. Но вы можете использовать его как пример кода: https://github.com/dima117/thinking-home/tree/1e198d3cff1abc0643020db8972f9cd6fdd91a66/ThinkingHome.Plugins.OneWire
Умный дом на .NET — релиз ThinkingHome 3.0