Как построить “Умный дом" и не сойти с ума

image

Умная мебель, которая сама заботится о порядке в доме, — must-have почти любой футуристической картины. На самом деле саморегулирующееся климат, автоматическое включение и выключение света и голосовое управление бытовой техникой — всё это можно настроить уже сейчас. Но понадобится немного опыта, базовых знаний в области техники и иногда программирования, а также целое море фантазии. В моем же случае, я сделал так что достаточно только фантазии, но обо всем по порядку…

Самой идеей «умного дома» я заинтересовался около пяти лет назад. Сначала я сделал самую простую систему. Она управляла светом в коридоре и ванной по датчику движения, вытяжкой по датчику влажности, а также погодной станцией  —  в то время по ним все сходили с ума. Каждый уважающий себя DIY-щик должен был сделать погодную станцию.

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

Если кто-то шел в ванную комнату, то его движение фиксировал коридорный датчик и тут же включал свет и в коридоре, и в ванной. При этом, если в ванную никто не заходил, то это уже фиксировал датчик, находящийся внутри ванной комнаты. Спустя 15 секунд свет там выключался. Если человек заходил в ванную, то свет в коридоре выключался через минуту. 

Я продумал и такие случаи, если кто-то слишком задумывался, сидя на «белом друге» в ванной (у меня был совмещенный санузел). Для этого свет в ванной был поделен на две группы. Одна выключалась через 3 минуты после того, как датчик в ванной переставал фиксировать движения, другая  —  через 5 минут. Так что больше чем на пять минут оставаться без движения в ванной при свете не получалось. Очень дисциплинирует. Впрочем, можно было всегда пошевелить рукой и продолжить думать о насущном.

В ванной также работал датчик влажности, который автоматически запускал вытяжку, если влажность превышала 50%. Как только помещение проветривалось до 45% влажности, вытяжка выключалась. 

Управление шло  —  а точнее пыталось идти  —  через платформу Arduino. 


Фото взято с сайта производителя

Почти сразу стало понятно, что эта платформа   —   не совсем про создание умного дома. Основное неудобство работы с Arduino сводилось к тому, что платформа работала без сети, а без нее не получалась никакой по-настоящему единой экосистемы.  Конечно, я мог бы переделать Arduino и добавить поддержку сети, но зачем? Я выбрал более простой путь и сменил эту платформу на другую. 

Наигравшись с Arduino, я переподключил дом на плату ESP-8266. По сути это тот же Arduino, но с Wi-Fi + компактнее по размерам.  Этот модуль до сих пор пользуется популярностью у производителей гаджетов для умного дома. 


Фото взято из Интернета

Параллельно я пытался сделать умный дом еще более умным. Например, решить проблему круглосуточно работающих теплых полов или вечно включенного кондиционера. Для этого я купил китайские WiFi-термостаты Beok. Они позволили отключать подогрев пола дистанционно, но приходилось это делать через специальное приложение в телефоне. 

Задачу по дистанционному управлению кондиционером я решил с помощью эмулятора инфракрасных сигналов Broadlink RM Pro. Ничего сложного: записываешь на эмулятор сигнал с пульта управления кондиционером (тут может быть любая техника, управляемая с помощью пульта), а потом в телефоне нажимаешь кнопочку в приложении, и эмулятор воспроизводит ранее записанный сигнал. В случае с кондиционером я получил возможность включать и выключить его, задавать режим работы и выставлять другие параметры удаленно.  

Также установил выключатели Livolo. С их помощью я мог также включать и выключать свет по радиоканалу. 



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

В доме также появились различные управляемые WiFi-реле типа Sonoff или Tuya и даже дорогущий Danalock для замка в квартиру, к которому тоже потребовалось отдельное приложение. Почти все эти мелочи (за исключением Danalock) я покупал на китайской площадке Aliexpress, где они стоили копейки и позволяли мне экспериментировать без серьезных вложений. 

Одной из первых относительно серьезных покупок стал бризер от Tion. С автоматическим контролем CO2 он более или менее справлялся, но температуру подогрева воздуха зимой постоянно приходилось регулировать вручную. И снова  —  для управления пришлось установить отдельное приложение. 


Фото взято с сайта производителя

Всех датчиков и контроллеров, которые я тогда испробовал, я даже не могу вспомнить. Мой смартфон был забит приложениями по их управлению. Это был целый зоопарк, за которым постоянно приходилось следить. Я попытался объединить управление этими приложениями через всякие агрегаторы типа HomeBridge/MajorDomo и т.п. Но у всех обнаружились свои существенные недостатки:

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

Поиски какого-либо приложения для централизованного управления такого объема датчиков, контроллеров и других систем управления к успеху не привели. Тогда же я попробовал самостоятельно довести до ума одно из «умных» устройств  —  тот самый бризер Tion. Я написал скрипт для автоматического управления температурой нагрева в зависимости от температуры в помещении. Дело в том, что у системы вентиляции не было автоподстройки температуры нагрева воздуха. Получалось, что в помещении было то супержарко, то суперхолодно. Никак не выходило добиться золотой середины. Вот с помощью написанного скрипта и бризера эту задачу удалось решить. 

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

Около года я самостоятельно занимался back-end и front-end разработкой приложения. 

Серверная часть написана на NodeJS. Выбор в пользу NodeJS был сделан из-за развитого сообщества, в котором имеются реализованные протоколы практически ко всем имеющимся на рынке устройствам. Клиентская часть написана на Angular (Ionic) и работает на Android/iOS. В общем классическая клиент-серверная архитектура.

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

Я многократно переписывал драйвера устройств, пока не пришел к примерно такому виду:

Пример кода одного из устройств
import {XiaomiSubdeviceV2} from '../xiaomi.subdevice.v2';
import {load_power} from '../capabilities/load_power';
import {power_plug} from '../capabilities/power_plug';
import {PowerPurpose} from '../../base/PowerPurpose';
import {Relay} from '../../base/types/Relay';
import {HomeKitAccessory} from '../../hap/HomeKitAccessory';
import {Lightbulb2Accessory} from '../../hap/Lightbulb2Accessory';
import {Yandex} from '../../yandex/Yandex';
import {YandexLightOrSwitch} from '../../yandex/YandexLightOrSwitch';

export class LumiPlug extends XiaomiSubdeviceV2.with(Relay, power_plug, load_power, PowerPurpose,
  HomeKitAccessory, Lightbulb2Accessory,
  Yandex, YandexLightOrSwitch) {

  onCreate() {
    super.onCreate();
    this.model = 'Mi Smart Plug';
    this.class_name = 'lumi.plug';
    this.driver_name = 'Mi Smart Plug';
    this.driver_type = 3;
    this.parent_class_name = 'lumi.gateway';
  }

  getIcon() {
    return 'socket';
  }
}


Суть в том, что несмотря на обилие различных устройств, все они делают приблизительно одно и то же и предоставляют примерно одинаковую информацию. Поэтому все возможности устройств были вынесены в отдельные примеси, из которых в конечном итоге и состоит окончательный драйвер. Например, в приложении поддержано множество устройств, имеющих функцию включить/выключить. Она-то и вынесена в отдельную примесь и идентично используется для всех девайсов. Элементарно же, Ватсон!

Что это дало в итоге: любой драйвер нового устройства пишется довольно быстро и легко, т.к. все стандартизировано и не нужно беспокоиться о дальнейшем хранении полученной информации. Для совсем новых протоколов (которых у меня еще не было) также пишутся примеси, которые основаны на имеющихся. Уже они получают информацию устройства и передают ее далее по цепочке. Подобный подход позволил сократить объем кода в десятки раз (изначально каждый драйвер был копией похожего драйвера).

Так постепенно я проходил все круги ада по допиливанию бэка и фронта. Когда приложение приобрело достаточно сносный вид, я подумал: почему бы не поделиться своей разработкой с общественностью? Были найдены партнеры для проекта и помощники для доведения приложения до ума. 

В первую очередь, довести до ума надо было дизайн приложения. Для этого пришлось обратиться к профессиональным дизайнерам. Я наивно полагал, что на это уйдет 3-4 месяца, но в итоге процесс затянулся. Не смотря на то что структура приложения не сильно изменилась от первоисточника, переделывать пришлось буквально все.

Параллельно я — уже не в одиночку, а вместе с командой партнеров по проекту — скупал наиболее популярные устройства для умного дома и дописывал приложение, если оно не поддерживало эти гаджеты. Вскоре, впрочем, стало понятно, что денег на все умные устройства не хватит, поэтому мы решили пообщаться с существующими игроками на рынке и договориться о бесплатных тестовых образцах оборудование бесплатно. Нам не отказали, и первыми серьезными поставщиками стали Wirenboard и MiMiSmart.

Так я вместе с ребятами создал новое приложение для автоматизации умного дома с классической клиент-серверной архитектурой, которая ставится на любую платформу, и удобным современным дизайном. Знакомьтесь  —  BARY*.

*Название произошло не от имени Бари Алибасова, а от персонажа книги Артура К.Дойля «Собака Баскервиллей» дворецкого Бэрримора (англ. Barrymore) —  ваш личный «умный дворецкий». 

Что получилось: описание приложения с красивыми картиночками и котиками


Главный экран представляет из себя удобный дашборд с возможностью просмотра и управления параметрами автоматизируемых помещений. Удобный  —  тут ключевое слово, потому что дашборды в тех приложениях, с которыми я сам пытался работать, было необходимо конфигурировать вручную. Не самое приятное времяпрепровождение



Дом можно поделить на зоны, а зоны — на комнаты. У каждой комнаты есть различные параметры: температура, влажность, текущее потребление электричества и пр., а также избранные действия. Если нажмем на комнату, то провалимся в список подключенных к ней устройств:



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

Все устройства подключаются при помощи однотипных настроек. Для многих девайсов есть мастер подключения. Никаких конфигов для тех, кто любит погорячее! В основном все сводится к указанию IP-адреса устройства (для многих устройств есть автопоиск). Если IP-адрес вдруг поменяется, то ничего страшного, сервер найдет его по новому адресу автоматически.



Есть интеграция с Apple HomeKit, она используется для голосового управления через Siri. Все девайсы, поддерживаемые в BARY, интегрируются с Apple HomeKit нажатием одной галочки (привет любителям HomeBridge). Не обошлось и без поддержки Яндекс Алисы. Она оказалась более дружелюбна с точки зрения интерфейс-команд. Например, Siri не хочет закрывать шторы по команде «закрой шторы», не может выставить определенное значение громкости на ТВ и прочее. У Яндекс.Алисы таких закидонов нет. 

Для удобства управления умными угодьями реализованы автоматизации: правила исполнения каких-либо действий при выполнении комплекса условий. Автоматизации логические,  многоуровневые, т.е. можно сделать что-то типа: «Условие 1 и (Условие 2 или Условие 3)». Все в логичном красивом редакторе автоматизаций:



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



В приложении также поддерживаются сценарии. Сценарий — комплекс действий, выполняющийся при каком-либо условии из автоматизации.  Для своего умного дома я использую только стандартный набор:



У меня уход из дома / возвращение домой реализованы через Apple TV — включается/выключается автоматически когда все ушли из дома, или кто-то вернулся домой. Приходишь домой, а тебя там уже встречает диктор с грустными глазами с 1го канала. Ну здорово  же?

Ну и какой же умный дом без возможности наблюдать за котиком?



Можно подключить любую камеру, которая способна отдавать RTSP-поток. 

Отдельно хочу сказать о блоке статистики. Получилось достаточно информативно:



В легенде красная полоса — отклонение от средних значений за последние полгода, серая полоса — расход в пределах  средних значений.

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

Также статистику можно посмотреть по любому подключенному устройству:



Кстати, наличие автоматизаций и статистики сократили расходы на электричество более чем в 2 раза.

Все возникающие события хранятся, и их можно посмотреть:



Также на главной странице есть особая вкладка, которая собирает все выбранные пользователем основные показатели:



Кстати, учет воды реализован через датчик открытия дверей/окон Xiaomi. Для этого вместо геркона на специальный контакт припаивается выход с импульсного счетчика, а в BARY создается виртуальный счетчик, у которого в качестве источника импульсов можно указать этот датчик.

Архитектура и безопасность


Обмен клиента с сервером зашифрован по технологии AES, а сервер находится непосредственно внутри автоматизируемого помещения. На мой взгляд, это максимально защищает систему от сторонних нежелательных вмешательств.

Если нет белого IP-адреса, то можно подключить облако. Оно будет являться посредником, без возможности расшифровки команд, т.к. ключи находятся на сервере. 

Где взять


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

Для Raspberry Pi на базе Debian Stretch:

wget -qO- "http://bary.io/install?target=pi" | sudo bash

Параметр target отвечает за целевую платформу и может иметь следующие значения:
Raspberry Pi (Debian Stretch)
pi
Raspberry Pi (Debian Buster)
pi_buster
Tinker Board (Debian Stretch)
tb
Wiren Board (Debian Stretch)
wb

Если у кого-то будет желание установить на другую платформу, напишите нам, и мы обновим скрипт. Если возникнут какие-то трудности — тоже пишите. Нам очень нужна обратная связь. 

Приложение в свободном доступе на Google Play и App Store. Возможно, к концу года, приложение станет платным.

Заключение


Зачем я написал эту статью? Основная цель – получить обратную связь от вас.

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

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

Ближайшие планы и радужные хотелки


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

В следующем году планируем больше интеграций с различными сервисами: списком покупок и дел, календарем и т.д. Подошел, посмотрел на один экран -  и все как на ладони. Несколько проектов, реализованных «под ключ», показали, что эта задача актуальна.

Также планируем старт производства контроллеров с предустановленным ПО для пакетных решений умного дома (в настоящее время пакетное решение «ПО+железо» доступно совместно с нашими партнерами Wiren Board.

А еще поддержка Google Home и Amazon Alexa. Ну и расширение номенклатуры поддерживаемого оборудования, само собой.

Кстати, кому интересно, можете посмотреть перечень поддерживаемых девайсов (не полный) на нашем сайте, а если чего-то в списке не нашли, то спросить в телеграмм-группе.

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

Всем спасибо, кто дочитал. Давайте сделаем свои дома умнее вместе!
BARY.io
Меня зовут BARY, я подружу все ваши IoT устройства

Similar posts

Comments 55

    +1
    Голосового помощника не пробовали подключить? Я изучал вопрос по поводу возможности подключения Алисы для самодельной платы управляемого реле. Но столкнулся с непреодолимой проблемой, что Алиса требует наличие домена и выхода в интернет. Что противоречило идее сделать полностью автономную систему, управляемой домашним сервером.
      +1
      Полностью согласен. Весь умный дом на мой вкус надо поручить голосовому помощнику. Консьерж электронный. И свет включает и такси вызывает и пиццу на доставку сможет оформить. Я бы купил такую систему сразу. До 50 кило рублей, но должно работать очень хорошо. И пусть ещё за коммуналку сам платит.
        +2
        Возможно когда-нибудь, мы придем к такому) Яндекс много в этом направлении уже сделал, а интеграция с яндексом у нас есть.
          0
          За коммуналку платить есть такой.
          +2
          Добрый день. Голосовые помощники поддерживаются — Сири и Алиса, Гугл позже будет. В статье об этом написано. Сири например полностью автономна, только само распознавание голоса через интернет. В случае Алисы и распознавание и запросы только через интернет.
          +2
          Суть в том, что несмотря на обилие различных устройств, все они делают приблизительно одно и то же и предоставляют примерно одинаковую информацию. Поэтому все возможности устройств были вынесены в отдельные примеси, из которых в конечном итоге и состоит окончательный драйвер. Например, в приложении поддержано множество устройств, имеющих функцию включить/выключить. Она-то и вынесена в отдельную примесь и идентично используется для всех девайсов. Элементарно же, Ватсон!


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

          Там была совсем другая архитектура (распределенная система на микроядреной архитектуре). Общая суть такова — есть «контроллер верхнего уровня» — IP-шлюз (в системе их может быть до 254). С одной стороны у него UDP сокет, с другой — линия RS-485 к которой цепляются контроллеры нижнего уровня (тоже до 254 на линию) — «устроства сопряжения с объектом» — УСО. К УСО уже подключаются непосредственно сами устройства (там модульная архитектура, позволяющая втыкать нужны набор плат электрических интерфейсов под разные классы устройств).

          Ну это так, лирика. Одной из проблем, еще в начале разработки общей архитектуры была проблема описания устройств. И была разработана система классов и свойств устройств.

          Например, обычный датчик «сухой контакт», имеющий два состояния — замкнуто и разомкнуто обладает следующими признаками:

          1. Нормальное состояние — on, off, both
          Первые два понятно — описывается состояние которое считать нормальным, противоположное состояние считается аварийным и при переходе в него генерируется аварийное сообщение. Третий же вариант описывает «информационный» датчик. У него нет состояния аварии, он не является самостоятельным источником аварийных сообщений, но информацию о его состоянии можно получить по запросу.

          2. Триггер — yes, no
          Это свойство характеризует возврат из аварийного состояния в нормальное — если yes, то даже когда физически датчик вернулся к нормальному состоянию, УСО все равно будет считать его «аварийным» до поступления специальной команды «сброс».

          3. Задержка (в секундах)
          Это достаточно специфический параметр. У нас были датчики, которые при нормальной работе могли «моргать». Т.е. он или находится в нормальном состоянии, или переходит в аварийное, потом снова в нормальное. И аварией считается не то, что он перешел в аварийное состояние, а то, что он в нем непрерывно находился в течении заданного времени.
          В частнсти, так работали старые советские лифты — у них было реле контроля дверей шахты (РКД) и реле индикации точной остановки (РИТО) — «лифт на этаже». Так вот РКД замыкался при закрытых дверях, а РИТО когда лифт стоит напротив дверей шахты. Это нормальные их состояния. Но когда лифт движется, РИТО «моргает» — размокнуто между этажами и замыкается при проходе этажа. Это нормально. Ненормально когда РИТО долго (скажем, больше минуты) непрерывно разомкнуто — значит лифт завис между этажами. Или когда РКД разомкнуто более 3-х минут — двери шахты заклинило.

          Это признаки, которые загружались для устройства в УСО. На стороне клиента, в конфигурационной БД, дополнительно прописывалось местоположение устройства, строковые описания состояний, аварийные сообщения и т.п. При возникновении аварии от УСО к IP шлюзу и далее шел сигнал «авария» с идентификатором устройства. Когда сигнал поступал в интерфейсный клиент, он уже по данным из БД его расшифровывал в человеческий вид типа
          «ул.Средняя, д.6, грузовой лифт 5-й подъезд — Лифт между этажами».

          Дополнительно можно было связывать устройства. Скажем, если в лифте есть датчик пола, то при возникновении аварии РИТО считывалось и посылалось его состояние, тогда приходило две посылки — авария от РИТО + состояние датчика пола — «ул.Средняя, д.6, грузовой лифт 5-й подъезд — Лифт между этажами, в кабине люди».

          Также была классификация механизмов. Там проще —
          1. Признак типа — ручной, полуавтомат
          2. Задержка — для полуавтоматов задержка выключения в секундах.
          Т.е. включается посылкой команды, выключается автоматически через заданное время.

          На стороне клиента еще мог указываться тип «автомат» с расписанием включений-выключений, но для УСО это был ручной механизм, автоматикой тут рулил сам клиент.

          Тут также можно было связывать устрйоства. Скажем, ручной механизм + инфрмационный датчик. После посылки команды на механизм, опрашивался датчик и высылалось его состояние. Например, управление освещением подъезда. Команда на включение, в ответ состояние датчика освещенности — включился или нет.

          Были и интеллектуальные устройства со своим контроллером. Но тут УСО для них было просто прозрачным мостом, вся обработка шла на стороне клиента.

          Вся логика обработки была на стороне клиента. Была разработана концепция «драйвера устройства». Для каждого класса устройств свой драйвер. Клиенты работали под виндой, драйвера были в DLL. Универсальный интерфейс на основе датаграмм позволял подгружать драйвера на ходу, без остановки системы. Т.е. «добавить устройство» — «новый класс» — «выбрать драйвер»… Дальше уже весь интерфейс конфигурации устройства был в драйвере.
          В драйвер же поступали на обработку все посылки от устройства. А он уже их обрабатывал и выдавал в интерфейс что нужно сделать — вывести аварийное сообщение или еще что-то…

          Все это было завязано на т.н. микроядро — некий маршрутизатор-фильтр к которому с одной стороны по UDP протоколу подключались IP-шлюзы, с другой, по TCP протоколу, интерфейсные клиенты (там тоже был зоопарк — клиенты были общие, специализированные, могли получать всю информацию из системы или работать с ограниченными наборами устройств — всем этим, кому чего посылать, и рулило микроядро, кроме своей основной функции — реализации отношения «многие ко многим»).

          В целом сложновато чтобы все описать вот так в одном комменте, но суть такая — постараться составить формальную классификацию устройств по принципу «класс + набор характерных признаков», сделать некоторый «сервер», который будет хранить конфигурацию системы и отслеживать ее текущее состояние (тут, боюсь, малинки может и нехватить) и, скажем, вебморду, на которой можно будет видеть и управлять всем хозяйством издаля.
            +1
            Спасибо, что поделились своим опытом. У нас пока только домашняя автоматизация, и заложенных в нее возможностей хватает.
              0
              Я в этой теме более 25-ти лет варился. Начинали еще когда вообще аналогов не было (92-93 год, насколько помню). Так что все с нуля делали.

              Шишек набили, но многие архитектурные решения оказались удачными настолько что переносились из версии в версию. В частности, система драйверов устройств с универсальным интерфейсом (когда вся специфика внутри драйвера) и система классификации устройств (она расширялась по мере появления новых типов и классов, но основа осталась то, что была заложена в самом начале).
                0
                Ну у меня опыта поменьше конечно, но шишек тоже немало набили. Много хлама перепробовать пришлось, много чего погорело из-за иногда неровных рук. Но сама основа тоже думаю надолго хватит и масштабируется при этом легко. А вообще был еще 10-летний опыт работы со всякими фискальниками, кардридерами, замками электронными и подобного оборудования, там не только шишек набил.
            0
            В настоящее время проект стремительно развивается, и вся наша команда старается предельно расширить перечень поддерживаемого оборудования, имеющегося на рынке. Хотя над проектом работаю уже не я один, задачи остались те же — создать максимально удобное приложение, которое учитывает пожелания и решает проблемы всех, кто занимался самостоятельной установкой смарт-решений для дома.


            По моему опыту просто приложения будет мало. Нужен комплекс. Железо + софт. Причем, управление не на уровне «хлопнул в ладоши — свет зажегся», это все прикольно, но реальной пользы мало.

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

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

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

            И т.д. и т.п.

            Плюс надежность и отказоустойчивость — если у вас упал сервер, основное оборудование (то же отопление) должно продолжать работать пусть и по неэффективным алгоритмам, но обеспечивать приемлемый уровень комфорта.

            В общем, если к вопросу подойти серьезно, там очень много граблей разложено.
              0
              У нас все делается правилами и управление климатом в том числе. У меня в квартире реализована поддержание как температуры (кондиционеры летом, батареи и теплые полы зимой), влажности (в каждой комнате увлажнитель), проветривание (бризеры тион в каждой комнате). Сейчас в проекте дом, где вентиляция уже будет во всем доме, с клапанами в каждой комнате. Причем и вентиляция и кондиционирование сразу, плюс отопление и теплыми полами и радиаторами и конвекторами (все водяное).
              Нам пока просто софта более чем достаточно, т.к. оборудования на рынке итак уже много на любой вкус и цвет и мы можем подбирать под конкретный проект любое оборудование.
              Отказоустойчивость софта достаточно высокая и мы продолжаем работать над ее улучшением.
              Граблей за 3 года работы над проектом повидали немало.
              Ну и в квартире я использую оборудование на климат у которых состояние не вкл/выкл, а поддержание заданных условиях, т.е. даже если все упадет, оборудование продолжит работать на заданных условиях.
                0
                Тут еще вопрос цены. То, что есть на рынке имеет неслабые накрутки. Мы в свое время отказались от промконтроллеров Octagon MicroPC по ому что цена получалась заоблачной и клиенты сразу начинали смотреть в другую сторону.

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

                А подключать приходилось много чего — лифтовые контроллеры (УБДЛ и еще какие-то другие), теплоэнергоконтроллеры (Карат, ТСТ, ТЭКОН...). Это не считая различных датчиков и исполнительных механизмов.
                  0

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

                    0
                    Т.е. вы пишете софт под железо пользователя? Адаптируетесь под имеющиеся протоколы того железа, которое выбирает пользователь?

                    Мы тоже так делали — все конечные устройства были клиента, мы тут ничего не диктовали. Мы предоставляли только свои контроллеры и софт. И подключали к ним уже то, что есть у клиента. Потому и пришли к классификации устройств и подгружаемым драйверам. Чтобы система была расширяема на ходу, причем, без ее остановки В наших условиях останавливать систему для обновления в случае появления у клиента нового устройства, которое мы заранее не предусмотрели, было неприемлимо. Например, для систем ЛДСС (лифтовая диспетчерская связь и сигнализация — одно из основных наших применений) есть ПУБЭЛ (правила установки и безопасной эксплуатации лифтов), по которым лифт не может эксплуатироваться если нет системы диспетчеризации. Т.е. остановка системы означает предварительную остановку всех подключенных лифтов. А потом их включение обратно. А их в системе может быть несколько сотен. И раскиданы они по всему городу (сейчас УК работают экстерриториально). Т.е. введение в систему любого нового типа устройства должно происходить без ее остановки, путем подключений нового драйвера.

                    Ну а классификация простых устройств через набор признаков вообще позволяла такие вещи как датчики охраной, пожарной сигнализации, протечек и прочего подключать просто сконфигурировав их набор свойств + текстовые описания самого датчика и его состояний. Такие простые вещи клиент вообще мог сам делать — подключить датчик к клеммам на УСО и описать его в софте.

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

                    Плюс логирование всего и вся (включая записи разговоров диспетчера с кабинами лифтов).
                      0
                      Примерно так, да. Но мы можем и свои рекомендации дать, если вдруг клиент захочет что-то странное.
                      У вас, видимо, уже более серьезная автоматизация под объекты жкх, так?
                      Там я конечно понимаю, что требования другие. Мы пока в этот рынок не смотрели особо, но об описанных Вами сложностях прекрасно понимаем. У нас домашняя автоматизация, но правила чуть сложнее устроены, чем у подобных проектов. В будущем мы будем расширять возможности, если это будет востребовано, включая и возможность работы нон-стоп.
                        0
                        Ну мы начинали с ЛДСС (тогда оно называлось ОДС — объединенная диспетчерская связь). Еще в те времена, когда ничего подобного на рынке не было — в диспетческих стояли ПД-32 (пульт диспетчера на 32 лифта).Там на каждый лифт было три лампы (РИТО, РКД и вызов голосовой связи из кабины) и кнопка коммутации линии связи с кабиной. От каждой лампы шел отдельный провод к соответсвующему устройству. Т.е. пучки проводов по микрорайону и никакой автоматизации.

                        Первые контроллеры у нас были на Intel 8080 и было две пары — голос и данные. Плюс софт на компе где была карта района с обслуживаемыми домами и выводидись сообщения от устройств. Ну и логирование всего что происходит.

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

                        Это потом уже появились конкуренты (которые во многом копировали наши решения, по крайней мере в плане интерфейса точно).

                        Дальше уже развивались в более универсальную систему, которая может мониторить оборудование, распределенное в большом районе. Но ЛДСС оставалось одним из основных направлений работы.

                        На самом деле, принцип там один везде — есть некоторое устройство, обладающее собственной автоматикой (в нашем случае это теплоэнергоконтроллеры, система пожарной сигнализации и дымоудаления, лифтовые контроллеры...), есть каналы связи, позволяющие мониторить работу системы и есть возможность корректировать работу встроенной автоматики как в ручную, так и по заложенным алгоритмам.

                        Обязательно — система оповещения о критических ситуациях. Пожар, протечка воды, отключение электричества, выход параметров за пределы заданных режимов и т.п.
                  0
                  А позволяет ли Ваша система непосредственно рулить вентиляцией?
                  Включать/выключать вентиляторы через DO или AO (для EC вентиляторов)
                  Управлять водяным или электричесикм калорифером.
                  Принимать данные с датчиков.
                  Рассчитывать ПИД регулирование…
                  Т.е. делать всё то, что делают контроллеры автоматизации.

                  Спрашиваю, иббо меня не покидает желание для домашней системы вентиляции найти решение, совмещающее в «одном флаконе» и бэкенд, рулящий физическими средами и обрабатывающий датчики, и фронт-енд, рисующий GUI.
                  Всё, что нахоже — требуют программирования двух сущностей.
                  А разработчики GUI решений почему-то :) всегда считают, что есть уже КТО-ТО, запрограмировавщий контроллер вент.машины. И не не желают самим стать этим кем-то :)
                    0
                    Реальный кейс есть пока только на одной двухкомнатной квартире с помощью двух тионов (еще один кейс тоже с двумя тионами в работе). Кейс прямо под Ваше описание сейчас в работе — это 3-х этажный загородный дом, в котором и отопление и вентиляция и кондиционирование будут реализованы через BARY.
                    Мы разрабатываем комплексное решение и заинтересованы в полноценном управлении)
                    Включать/выключать, снимать показания и делать под это дело правила уже умеем.
                    Если есть желание помочь, присоединяйтесь в телеграмм канале.
                0
                Расширение платформ для сервера было бы очень в тему. Windows, Linux как минимум.
                Таки лично мне проще поднять сервер на виртуалке, что бы попробовать, чем покупать оборудование для системы, которая может и не пригодится.
                  0
                  Поддерживаются все платформы. И Linux и MacOs и Windows. Просто автоматические скрипты сделаны только на те системы, которые самим встречались. Можете развернуть виртуалку на дебиан и протестировать.
                    0
                    «Поддерживаются все платформы. И Linux и MacOs и Windows.»
                    Но как установить сервер например на винду? На сайте дистрибутива нет.
                    И нескольк не понял — зачем в программе для андроид нужна регистрация?
                      0
                      Если захотите поставить — можете связаться со мной через группу в телеге, я скажу как. Дистрибутив один на все платформы.
                      Регистрация нужна для облачных функций. Использовать облако или нет по Вашему желанию, мы не навязываем.
                        0
                        «Если захотите поставить — можете связаться со мной через группу в телеге, я скажу как.»
                        Ну тут к сожалению мимо — в телеграмме не зарегистрирован и не планирую.
                        Как факт (Вы просили указать предложения) — это как минимум усложняет использование.
                        «Регистрация нужна для облачных функций.»
                        Но без регистрации использовать не получается, что тоже с моей точки зрения не правильно. Лично я ставить точно не буду, как другие не знаю.
                          0
                          Если бы мы описывали установку под все системы, то и без того немаленькая статья стала бы совсем неподъемной. На данный момент приложение бесплатное и просьба зарегистрироваться это меньшее зло. Мы учтем ваши пожелания в коммерческой версии продукта.
                      0
                      А почему не сделать вебморду на домашнем сервере? Это куда более универсально.

                      Простейший пример — хочу с рабочего компа на работе этим всем управлять. Ну или хотя бы наблюдать. Одна беда — выход в инет на нем нет. Только внутренняя сеть (это требования УИБ, их не обойти). Но есть «безопасный браузер» (фактически, он стоит на другой машине, я вижу только картинку). Т.е. через браузер выйти в нет могу, но никакое другое приложение в с компа в сеть не попадет никак.

                      Вебморда сразу решит все эти проблемы. Не надо будет думать про разные операционки. Ну разве что мобильные приложения сделать как обертку для вебморды (ну или параллельный REST/SOAP API поддерживать для мобильных приложений). Как вариант — в основе REST API, доступ нему или через вебморду, или через мобильное приложение.

                      Все драйвера всех устройств работают на домашнем сервере. Управлять им через API. И не надо никаких облаков.

                      Сам сервер держит БД с конфигурацией и текущим состоянием системы. Он же опрашивает датчики, управляет механизмами по заданному расписанию (например, управление температурой в помещениях с целью экономии энергии — снижение температуры даже на 3 градуса когда дома никого нет уже ощутимо экномит энергозатарты на отопление). Он же посылает аварийные сообщения (SMS, e-mail) в случае ЧП (например, сработала пожарная сигнализация или датчик протечки). Он же позволяет получать SMS или e-mail с короткими командами.
                        0
                        Пока вебморда только в нашем облаке. Понятно, что локально удобнее, но пока только так. Телефон/планшет подрубить можно локально.
                          0
                          Ну я просто размышлял как сделал бы я. Как противник разных сторонних сервисов, которые в любой момент могут начать диктовать свои условия, которые могут допустить утечку данных и т.п.

                          Локальный сервер с белым IP или DynDNS, который управляет системой и имеет некую API (SOUP, Rest или пропертиарную, как было у нас в микроядре). А дальше или мобильное приложение или вебморда на этом же сервере.

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

                          Я как раз занимался разработкой микроядра. От архитектуры и протоколов до конечного кода. И был у меня технический клиент, который позволял видеть все, что там происходит на уровне кода (трейслоги) как в реальном времени, так и историю за последние 72 часа. Благодяря чему всегда мог ответить на вопрос типа «а что за фигня у них там на диспетчерской вчера в три часа ночи случилась?»
                    +3
                    docker бы запекли для пробы на рабочей машинке
                      +1
                      Сделаем.
                      +3

                      Так а чем это лучше раскрученных homeassist или openhab? Они тоже с различными устройствами умеют работать.


                      Что касаетя гибкости, то node-red позволяет подрубить к нему вообще практически всё от zigbee до rs485, а добавив туда mqtt можно подключить любой из десятков дашбордов из аппсторов.


                      Чем планируете их побеждать на рынке? :)

                        0
                        Когда я начинал работу над проектом что первый что второй были очень слабыми. Настраивать их только с бубном — в статье на это есть намек. Часовые видео на ютубе о подключении какой-то железки тоже не просто так выкладывают. Я же хотел сделать приложение более дружелюбнее к неподготовленному пользователю. Работы в этом направлении конечно еще много, но главная идеология такая и мы будем стремится ее реализовать в полном объеме. Побеждать их не планируем, это отличные проекты и у каждого из нас будет свой пользователь.
                          0
                          Лет 5 назад я пытался писать свой софт для умного дома, но у меня было оправдание — на рынке были только ужасные решения, вроде OpenHAB.
                          Я так потратил зря 2 года, и в итоге, разумеется, отказался от самописного велосипеда. Потому что сотни контрибьюторов Home Assistant развивают приложение гораздо быстрее и качественнее меня одного (или вас троих).
                          Вы уже очень далеко зашли в своём проекте, который все забудут года через 3, так что мне поздно уже советовать вам помогать сообществу писать интеграции в HASS. Это чтобы не нужно было смотреть потом часовые видео по настройке. Могли бы и продавать потом железки с HASS, оказывать платную поддержку точно так же, как со своим велосипедом.
                          Думаю, что вас ждёт печальная судьба вот этого проекта
                          habr.com/ru/post/382177
                        +1
                        Энергопотребление в кВт/ч, серьезно? Интересно, когда-нибудь это закончится.
                        Ладно, не будем о грустном, вопрос.
                        Планируется ли интеграция с Samsung Smart Things?
                          0

                          Не понял вашего сарказма. Энергопотребление в чем то другом измеряется?
                          Интеграция планируется с тем, на что будет спрос.

                            +2
                            Конечно в другом, взгляните на счетчик.
                            Энергопотребление измеряется в кВт * час, но никак не в кВт/час.
                              0

                              Исправлю, спасибо.

                                0
                                Насчет SmartThings, спрос есть и даже с возможностью монетизации.
                                Там наблюдается следующая проблема. Есть экосистема с устройствами и относительно нормальным приложением, но вот чего нет — это приложения или сервера, который бы отдавал дашбоард. Нужно это, чтобы разместить по дому что-то типа дешевых планшетов, которые бы показывали информацию и давали возможность чтем-то управлять.
                                У вас, судя по картинкам это и реализованно, причем выглядит очень красиво. Если бы вы добавили интеграцию с существующими системами умного дома, то автоматически получили бы доступ к огромному количеству уже установленных систем.
                                Есть подобные системы, например ActionTiles но выглядят они очень плохо.
                                  0

                                  Я имел ввиду спрос именно в нашем приложении. Хороших систем много и мы конечно хотели бы поддержать их все. Но в статье есть заметка по этому поводу — на данный момент мы не располагаем достаточными ресурсами для реализации всех систем.

                                    0

                                    Я посмотрел, он поддерживается проектом zigbee2mqtt, а он поддерживается у нас, только стик с zigbee 3 нужен. Ну и шаблоны прописать в нашем приложении. Если есть желание и можете помочь, то мы сможем реализовать поддержку не имея оборудования для тестов.

                                      0
                                      Там не все устройства ZigBee, есть еще Z-Wave. Да и потом стик же куда-то вставлять нужно. Samsung позволяет сторонним приложения подключиться прямо к аккаунту клиента и тогда все измерения доступны прямо оттуда, не надо насчет интеграции с устройствами вообще думать. Так работают ActionTiles и SharpTools.
                                      Есть еще открытый проект HousePanel тоже как-то достает данные напрямую из аккаунта.
                                        0

                                        Ну каких устройств нет, можно добавить попробовать, они это позволяют. А z-wave мы тоже поддерживаем. Причем можем через стик без стороннего ПО. Через облако можем сделать, но не сразу. А стик вставлять в raspberry pi, либо в наш хаб.

                              0
                              Классно все делаете. Жить в «Умном доме» не планирую, но проект всячески поддерживаю.
                                0

                                Так и не понял, как управлять умным домом с помощью одной лишь фантазии.

                                  0
                                  А как же Blynk? Бесплатный сервер, простая логика, отличный интерфейс клиента, простой и удобный, не такой детальный как у вас, но если не городить из квартиры центр управления полётами, вполне достаточно. Кстати, как вы считаете потребление электроэнергии по каждому прибору (интересует аппаратная часть)?
                                    0
                                    Когда я начинал Blynk только только появился. Это совсем другого рода софт — больше для diy.
                                    Считаю по разному, в щитке стоит WB-MAP12H от WirenBoard, в розетках подрозеточные модули Shelly/Fibaro/Xiaomi. Они с учетом энергопотребления. Самый топ Fibaro из подрозетников, считает отдельно по 2 каналам, но всего до 10А.
                                      0
                                      Благодарю за развернутый ответ с указанием устройств! Во время ремонта закладывал отдельные линии под каждую розетку, но прогадал с проводом, использовав неподатливый моножильный типа ВВГ. Тут с трудом на подрозетник места хватает. Остаётся вариант с девайсом в щитке.
                                        0
                                        Подрозетники бывают глубокими, но если у вас все линии до щитка, то WirenBoard идеален.
                                          +1
                                          Вы не прогадали. В закладной проводке, согласно СНИПам, можно использовать только моножилу. Многожильник использовать крайне не рекомендуется.
                                      0
                                      А чем это лучше HomeAssistant?
                                        0
                                        Выше уже отвечал на этот вопрос.
                                        0
                                        Выглядит очень круто, гораздо лучше чем, то что есть отдельно у Яндекса или Xiaomi, что только со своими устройствами может работать. Попробую и может напишу отзыв.
                                          0
                                          Спасибо! Будем рады обратной связи!
                                          0

                                          augap а Tion разрешил вам вклиниваться в их протокол и тиражировать это? о_О
                                          Или у них где-то API есть, которое можно официально использовать коммерческим решениям?

                                            0
                                            Пока не спрашивали. У нас некоммерческое решение.

                                          Only users with full accounts can post comments. Log in, please.