Comments 56
Голосового помощника не пробовали подключить? Я изучал вопрос по поводу возможности подключения Алисы для самодельной платы управляемого реле. Но столкнулся с непреодолимой проблемой, что Алиса требует наличие домена и выхода в интернет. Что противоречило идее сделать полностью автономную систему, управляемой домашним сервером.
Полностью согласен. Весь умный дом на мой вкус надо поручить голосовому помощнику. Консьерж электронный. И свет включает и такси вызывает и пиццу на доставку сможет оформить. Я бы купил такую систему сразу. До 50 кило рублей, но должно работать очень хорошо. И пусть ещё за коммуналку сам платит.
Возможно когда-нибудь, мы придем к такому) Яндекс много в этом направлении уже сделал, а интеграция с яндексом у нас есть.
За коммуналку платить есть такой.
Добрый день. Голосовые помощники поддерживаются — Сири и Алиса, Гугл позже будет. В статье об этом написано. Сири например полностью автономна, только само распознавание голоса через интернет. В случае Алисы и распознавание и запросы только через интернет.
Суть в том, что несмотря на обилие различных устройств, все они делают приблизительно одно и то же и предоставляют примерно одинаковую информацию. Поэтому все возможности устройств были вынесены в отдельные примеси, из которых в конечном итоге и состоит окончательный драйвер. Например, в приложении поддержано множество устройств, имеющих функцию включить/выключить. Она-то и вынесена в отдельную примесь и идентично используется для всех девайсов. Элементарно же, Ватсон!
В свое время занимался разработкой системы мониторинга инженерного оборудования зданий.
Там была совсем другая архитектура (распределенная система на микроядреной архитектуре). Общая суть такова — есть «контроллер верхнего уровня» — 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 протоколу, интерфейсные клиенты (там тоже был зоопарк — клиенты были общие, специализированные, могли получать всю информацию из системы или работать с ограниченными наборами устройств — всем этим, кому чего посылать, и рулило микроядро, кроме своей основной функции — реализации отношения «многие ко многим»).
В целом сложновато чтобы все описать вот так в одном комменте, но суть такая — постараться составить формальную классификацию устройств по принципу «класс + набор характерных признаков», сделать некоторый «сервер», который будет хранить конфигурацию системы и отслеживать ее текущее состояние (тут, боюсь, малинки может и нехватить) и, скажем, вебморду, на которой можно будет видеть и управлять всем хозяйством издаля.
Спасибо, что поделились своим опытом. У нас пока только домашняя автоматизация, и заложенных в нее возможностей хватает.
Я в этой теме более 25-ти лет варился. Начинали еще когда вообще аналогов не было (92-93 год, насколько помню). Так что все с нуля делали.
Шишек набили, но многие архитектурные решения оказались удачными настолько что переносились из версии в версию. В частности, система драйверов устройств с универсальным интерфейсом (когда вся специфика внутри драйвера) и система классификации устройств (она расширялась по мере появления новых типов и классов, но основа осталась то, что была заложена в самом начале).
Шишек набили, но многие архитектурные решения оказались удачными настолько что переносились из версии в версию. В частности, система драйверов устройств с универсальным интерфейсом (когда вся специфика внутри драйвера) и система классификации устройств (она расширялась по мере появления новых типов и классов, но основа осталась то, что была заложена в самом начале).
Ну у меня опыта поменьше конечно, но шишек тоже немало набили. Много хлама перепробовать пришлось, много чего погорело из-за иногда неровных рук. Но сама основа тоже думаю надолго хватит и масштабируется при этом легко. А вообще был еще 10-летний опыт работы со всякими фискальниками, кардридерами, замками электронными и подобного оборудования, там не только шишек набил.
В настоящее время проект стремительно развивается, и вся наша команда старается предельно расширить перечень поддерживаемого оборудования, имеющегося на рынке. Хотя над проектом работаю уже не я один, задачи остались те же — создать максимально удобное приложение, которое учитывает пожелания и решает проблемы всех, кто занимался самостоятельной установкой смарт-решений для дома.
По моему опыту просто приложения будет мало. Нужен комплекс. Железо + софт. Причем, управление не на уровне «хлопнул в ладоши — свет зажегся», это все прикольно, но реальной пользы мало.
Интереснее, скажем, система управления климатом для частного дома. Т.е. температура-влажность. А это значит, что вы должны управлять отоплением, кондиционированием и вентиляцией. Причем, достаточно гибко. Не на какой-то конкретный котел, а иметь несколько схем.
Например, электроконвекторы по комнатам + теплый пол + вентиляция + конлдиционеры. Плюс возможность задавать расписание — когда дома никого нет (в рабочее время, например), можно понизить температуру и получить экономию энергии. А к приходу хозяев опять выйти на режим. Или понизить температуру в неиспользуемых помещениях (ночью в гостиной, к примеру), но к утру опять выйти на режим.
Если то же отопление завязано на электричество, неплохо бы контролировать пиковую мощность и обеспечить приоритет включения мощных потребителей (чтобы оставаться в пределах максимальной пиковой мощности). Скажем, для тех же конвекторов обеспечить их включение по группам, а не всех сразу.
И т.д. и т.п.
Плюс надежность и отказоустойчивость — если у вас упал сервер, основное оборудование (то же отопление) должно продолжать работать пусть и по неэффективным алгоритмам, но обеспечивать приемлемый уровень комфорта.
В общем, если к вопросу подойти серьезно, там очень много граблей разложено.
У нас все делается правилами и управление климатом в том числе. У меня в квартире реализована поддержание как температуры (кондиционеры летом, батареи и теплые полы зимой), влажности (в каждой комнате увлажнитель), проветривание (бризеры тион в каждой комнате). Сейчас в проекте дом, где вентиляция уже будет во всем доме, с клапанами в каждой комнате. Причем и вентиляция и кондиционирование сразу, плюс отопление и теплыми полами и радиаторами и конвекторами (все водяное).
Нам пока просто софта более чем достаточно, т.к. оборудования на рынке итак уже много на любой вкус и цвет и мы можем подбирать под конкретный проект любое оборудование.
Отказоустойчивость софта достаточно высокая и мы продолжаем работать над ее улучшением.
Граблей за 3 года работы над проектом повидали немало.
Ну и в квартире я использую оборудование на климат у которых состояние не вкл/выкл, а поддержание заданных условиях, т.е. даже если все упадет, оборудование продолжит работать на заданных условиях.
Нам пока просто софта более чем достаточно, т.к. оборудования на рынке итак уже много на любой вкус и цвет и мы можем подбирать под конкретный проект любое оборудование.
Отказоустойчивость софта достаточно высокая и мы продолжаем работать над ее улучшением.
Граблей за 3 года работы над проектом повидали немало.
Ну и в квартире я использую оборудование на климат у которых состояние не вкл/выкл, а поддержание заданных условиях, т.е. даже если все упадет, оборудование продолжит работать на заданных условиях.
Тут еще вопрос цены. То, что есть на рынке имеет неслабые накрутки. Мы в свое время отказались от промконтроллеров Octagon MicroPC по ому что цена получалась заоблачной и клиенты сразу начинали смотреть в другую сторону.
А вот свои контроллеры на STM32 получились конкуретнтоспособны по цене и весьма надежны в работе. Плюс там была возможность модульной замены отдельных блоков и расширения блоками. Плюс мы в них закладывали то, что нам нужно и в результате могли подключать практически все, что управляется электричеством и имеет документированный протокол обмена.
А подключать приходилось много чего — лифтовые контроллеры (УБДЛ и еще какие-то другие), теплоэнергоконтроллеры (Карат, ТСТ, ТЭКОН...). Это не считая различных датчиков и исполнительных механизмов.
А вот свои контроллеры на STM32 получились конкуретнтоспособны по цене и весьма надежны в работе. Плюс там была возможность модульной замены отдельных блоков и расширения блоками. Плюс мы в них закладывали то, что нам нужно и в результате могли подключать практически все, что управляется электричеством и имеет документированный протокол обмена.
А подключать приходилось много чего — лифтовые контроллеры (УБДЛ и еще какие-то другие), теплоэнергоконтроллеры (Карат, ТСТ, ТЭКОН...). Это не считая различных датчиков и исполнительных механизмов.
Ну у нас суть проекта как раз в том, что пользователь сам может подобрать оборудование, которое может себе позволить. Понятно, что качество этого железа будет отличаться, но появляется свобода выбора в рамках единой экосистемы. Мы тут не первые, на первенство не претендую если что.
Т.е. вы пишете софт под железо пользователя? Адаптируетесь под имеющиеся протоколы того железа, которое выбирает пользователь?
Мы тоже так делали — все конечные устройства были клиента, мы тут ничего не диктовали. Мы предоставляли только свои контроллеры и софт. И подключали к ним уже то, что есть у клиента. Потому и пришли к классификации устройств и подгружаемым драйверам. Чтобы система была расширяема на ходу, причем, без ее остановки В наших условиях останавливать систему для обновления в случае появления у клиента нового устройства, которое мы заранее не предусмотрели, было неприемлимо. Например, для систем ЛДСС (лифтовая диспетчерская связь и сигнализация — одно из основных наших применений) есть ПУБЭЛ (правила установки и безопасной эксплуатации лифтов), по которым лифт не может эксплуатироваться если нет системы диспетчеризации. Т.е. остановка системы означает предварительную остановку всех подключенных лифтов. А потом их включение обратно. А их в системе может быть несколько сотен. И раскиданы они по всему городу (сейчас УК работают экстерриториально). Т.е. введение в систему любого нового типа устройства должно происходить без ее остановки, путем подключений нового драйвера.
Ну а классификация простых устройств через набор признаков вообще позволяла такие вещи как датчики охраной, пожарной сигнализации, протечек и прочего подключать просто сконфигурировав их набор свойств + текстовые описания самого датчика и его состояний. Такие простые вещи клиент вообще мог сам делать — подключить датчик к клеммам на УСО и описать его в софте.
Естественно, предусмотрена возможность отключения датчика (временная или постоянная) если он вдруг вышел из строя и начал генерить поток аварийных сообщений.
Плюс логирование всего и вся (включая записи разговоров диспетчера с кабинами лифтов).
Мы тоже так делали — все конечные устройства были клиента, мы тут ничего не диктовали. Мы предоставляли только свои контроллеры и софт. И подключали к ним уже то, что есть у клиента. Потому и пришли к классификации устройств и подгружаемым драйверам. Чтобы система была расширяема на ходу, причем, без ее остановки В наших условиях останавливать систему для обновления в случае появления у клиента нового устройства, которое мы заранее не предусмотрели, было неприемлимо. Например, для систем ЛДСС (лифтовая диспетчерская связь и сигнализация — одно из основных наших применений) есть ПУБЭЛ (правила установки и безопасной эксплуатации лифтов), по которым лифт не может эксплуатироваться если нет системы диспетчеризации. Т.е. остановка системы означает предварительную остановку всех подключенных лифтов. А потом их включение обратно. А их в системе может быть несколько сотен. И раскиданы они по всему городу (сейчас УК работают экстерриториально). Т.е. введение в систему любого нового типа устройства должно происходить без ее остановки, путем подключений нового драйвера.
Ну а классификация простых устройств через набор признаков вообще позволяла такие вещи как датчики охраной, пожарной сигнализации, протечек и прочего подключать просто сконфигурировав их набор свойств + текстовые описания самого датчика и его состояний. Такие простые вещи клиент вообще мог сам делать — подключить датчик к клеммам на УСО и описать его в софте.
Естественно, предусмотрена возможность отключения датчика (временная или постоянная) если он вдруг вышел из строя и начал генерить поток аварийных сообщений.
Плюс логирование всего и вся (включая записи разговоров диспетчера с кабинами лифтов).
Примерно так, да. Но мы можем и свои рекомендации дать, если вдруг клиент захочет что-то странное.
У вас, видимо, уже более серьезная автоматизация под объекты жкх, так?
Там я конечно понимаю, что требования другие. Мы пока в этот рынок не смотрели особо, но об описанных Вами сложностях прекрасно понимаем. У нас домашняя автоматизация, но правила чуть сложнее устроены, чем у подобных проектов. В будущем мы будем расширять возможности, если это будет востребовано, включая и возможность работы нон-стоп.
У вас, видимо, уже более серьезная автоматизация под объекты жкх, так?
Там я конечно понимаю, что требования другие. Мы пока в этот рынок не смотрели особо, но об описанных Вами сложностях прекрасно понимаем. У нас домашняя автоматизация, но правила чуть сложнее устроены, чем у подобных проектов. В будущем мы будем расширять возможности, если это будет востребовано, включая и возможность работы нон-стоп.
Ну мы начинали с ЛДСС (тогда оно называлось ОДС — объединенная диспетчерская связь). Еще в те времена, когда ничего подобного на рынке не было — в диспетческих стояли ПД-32 (пульт диспетчера на 32 лифта).Там на каждый лифт было три лампы (РИТО, РКД и вызов голосовой связи из кабины) и кнопка коммутации линии связи с кабиной. От каждой лампы шел отдельный провод к соответсвующему устройству. Т.е. пучки проводов по микрорайону и никакой автоматизации.
Первые контроллеры у нас были на Intel 8080 и было две пары — голос и данные. Плюс софт на компе где была карта района с обслуживаемыми домами и выводидись сообщения от устройств. Ну и логирование всего что происходит.
Пилотный проект ставили под эгидой конторы, которая занималась обслуживанием лифтов. За деньги этой конторы при условии что она берет объект на обслуживание.
Это потом уже появились конкуренты (которые во многом копировали наши решения, по крайней мере в плане интерфейса точно).
Дальше уже развивались в более универсальную систему, которая может мониторить оборудование, распределенное в большом районе. Но ЛДСС оставалось одним из основных направлений работы.
На самом деле, принцип там один везде — есть некоторое устройство, обладающее собственной автоматикой (в нашем случае это теплоэнергоконтроллеры, система пожарной сигнализации и дымоудаления, лифтовые контроллеры...), есть каналы связи, позволяющие мониторить работу системы и есть возможность корректировать работу встроенной автоматики как в ручную, так и по заложенным алгоритмам.
Обязательно — система оповещения о критических ситуациях. Пожар, протечка воды, отключение электричества, выход параметров за пределы заданных режимов и т.п.
Первые контроллеры у нас были на Intel 8080 и было две пары — голос и данные. Плюс софт на компе где была карта района с обслуживаемыми домами и выводидись сообщения от устройств. Ну и логирование всего что происходит.
Пилотный проект ставили под эгидой конторы, которая занималась обслуживанием лифтов. За деньги этой конторы при условии что она берет объект на обслуживание.
Это потом уже появились конкуренты (которые во многом копировали наши решения, по крайней мере в плане интерфейса точно).
Дальше уже развивались в более универсальную систему, которая может мониторить оборудование, распределенное в большом районе. Но ЛДСС оставалось одним из основных направлений работы.
На самом деле, принцип там один везде — есть некоторое устройство, обладающее собственной автоматикой (в нашем случае это теплоэнергоконтроллеры, система пожарной сигнализации и дымоудаления, лифтовые контроллеры...), есть каналы связи, позволяющие мониторить работу системы и есть возможность корректировать работу встроенной автоматики как в ручную, так и по заложенным алгоритмам.
Обязательно — система оповещения о критических ситуациях. Пожар, протечка воды, отключение электричества, выход параметров за пределы заданных режимов и т.п.
А позволяет ли Ваша система непосредственно рулить вентиляцией?
Включать/выключать вентиляторы через DO или AO (для EC вентиляторов)
Управлять водяным или электричесикм калорифером.
Принимать данные с датчиков.
Рассчитывать ПИД регулирование…
Т.е. делать всё то, что делают контроллеры автоматизации.
Спрашиваю, иббо меня не покидает желание для домашней системы вентиляции найти решение, совмещающее в «одном флаконе» и бэкенд, рулящий физическими средами и обрабатывающий датчики, и фронт-енд, рисующий GUI.
Всё, что нахоже — требуют программирования двух сущностей.
А разработчики GUI решений почему-то :) всегда считают, что есть уже КТО-ТО, запрограмировавщий контроллер вент.машины. И не не желают самим стать этим кем-то :)
Включать/выключать вентиляторы через DO или AO (для EC вентиляторов)
Управлять водяным или электричесикм калорифером.
Принимать данные с датчиков.
Рассчитывать ПИД регулирование…
Т.е. делать всё то, что делают контроллеры автоматизации.
Спрашиваю, иббо меня не покидает желание для домашней системы вентиляции найти решение, совмещающее в «одном флаконе» и бэкенд, рулящий физическими средами и обрабатывающий датчики, и фронт-енд, рисующий GUI.
Всё, что нахоже — требуют программирования двух сущностей.
А разработчики GUI решений почему-то :) всегда считают, что есть уже КТО-ТО, запрограмировавщий контроллер вент.машины. И не не желают самим стать этим кем-то :)
Реальный кейс есть пока только на одной двухкомнатной квартире с помощью двух тионов (еще один кейс тоже с двумя тионами в работе). Кейс прямо под Ваше описание сейчас в работе — это 3-х этажный загородный дом, в котором и отопление и вентиляция и кондиционирование будут реализованы через BARY.
Мы разрабатываем комплексное решение и заинтересованы в полноценном управлении)
Включать/выключать, снимать показания и делать под это дело правила уже умеем.
Если есть желание помочь, присоединяйтесь в телеграмм канале.
Мы разрабатываем комплексное решение и заинтересованы в полноценном управлении)
Включать/выключать, снимать показания и делать под это дело правила уже умеем.
Если есть желание помочь, присоединяйтесь в телеграмм канале.
Расширение платформ для сервера было бы очень в тему. Windows, Linux как минимум.
Таки лично мне проще поднять сервер на виртуалке, что бы попробовать, чем покупать оборудование для системы, которая может и не пригодится.
Таки лично мне проще поднять сервер на виртуалке, что бы попробовать, чем покупать оборудование для системы, которая может и не пригодится.
Поддерживаются все платформы. И Linux и MacOs и Windows. Просто автоматические скрипты сделаны только на те системы, которые самим встречались. Можете развернуть виртуалку на дебиан и протестировать.
«Поддерживаются все платформы. И Linux и MacOs и Windows.»
Но как установить сервер например на винду? На сайте дистрибутива нет.
И нескольк не понял — зачем в программе для андроид нужна регистрация?
Но как установить сервер например на винду? На сайте дистрибутива нет.
И нескольк не понял — зачем в программе для андроид нужна регистрация?
Если захотите поставить — можете связаться со мной через группу в телеге, я скажу как. Дистрибутив один на все платформы.
Регистрация нужна для облачных функций. Использовать облако или нет по Вашему желанию, мы не навязываем.
Регистрация нужна для облачных функций. Использовать облако или нет по Вашему желанию, мы не навязываем.
«Если захотите поставить — можете связаться со мной через группу в телеге, я скажу как.»
Ну тут к сожалению мимо — в телеграмме не зарегистрирован и не планирую.
Как факт (Вы просили указать предложения) — это как минимум усложняет использование.
«Регистрация нужна для облачных функций.»
Но без регистрации использовать не получается, что тоже с моей точки зрения не правильно. Лично я ставить точно не буду, как другие не знаю.
Ну тут к сожалению мимо — в телеграмме не зарегистрирован и не планирую.
Как факт (Вы просили указать предложения) — это как минимум усложняет использование.
«Регистрация нужна для облачных функций.»
Но без регистрации использовать не получается, что тоже с моей точки зрения не правильно. Лично я ставить точно не буду, как другие не знаю.
А почему не сделать вебморду на домашнем сервере? Это куда более универсально.
Простейший пример — хочу с рабочего компа на работе этим всем управлять. Ну или хотя бы наблюдать. Одна беда — выход в инет на нем нет. Только внутренняя сеть (это требования УИБ, их не обойти). Но есть «безопасный браузер» (фактически, он стоит на другой машине, я вижу только картинку). Т.е. через браузер выйти в нет могу, но никакое другое приложение в с компа в сеть не попадет никак.
Вебморда сразу решит все эти проблемы. Не надо будет думать про разные операционки. Ну разве что мобильные приложения сделать как обертку для вебморды (ну или параллельный REST/SOAP API поддерживать для мобильных приложений). Как вариант — в основе REST API, доступ нему или через вебморду, или через мобильное приложение.
Все драйвера всех устройств работают на домашнем сервере. Управлять им через API. И не надо никаких облаков.
Сам сервер держит БД с конфигурацией и текущим состоянием системы. Он же опрашивает датчики, управляет механизмами по заданному расписанию (например, управление температурой в помещениях с целью экономии энергии — снижение температуры даже на 3 градуса когда дома никого нет уже ощутимо экномит энергозатарты на отопление). Он же посылает аварийные сообщения (SMS, e-mail) в случае ЧП (например, сработала пожарная сигнализация или датчик протечки). Он же позволяет получать SMS или e-mail с короткими командами.
Простейший пример — хочу с рабочего компа на работе этим всем управлять. Ну или хотя бы наблюдать. Одна беда — выход в инет на нем нет. Только внутренняя сеть (это требования УИБ, их не обойти). Но есть «безопасный браузер» (фактически, он стоит на другой машине, я вижу только картинку). Т.е. через браузер выйти в нет могу, но никакое другое приложение в с компа в сеть не попадет никак.
Вебморда сразу решит все эти проблемы. Не надо будет думать про разные операционки. Ну разве что мобильные приложения сделать как обертку для вебморды (ну или параллельный REST/SOAP API поддерживать для мобильных приложений). Как вариант — в основе REST API, доступ нему или через вебморду, или через мобильное приложение.
Все драйвера всех устройств работают на домашнем сервере. Управлять им через API. И не надо никаких облаков.
Сам сервер держит БД с конфигурацией и текущим состоянием системы. Он же опрашивает датчики, управляет механизмами по заданному расписанию (например, управление температурой в помещениях с целью экономии энергии — снижение температуры даже на 3 градуса когда дома никого нет уже ощутимо экномит энергозатарты на отопление). Он же посылает аварийные сообщения (SMS, e-mail) в случае ЧП (например, сработала пожарная сигнализация или датчик протечки). Он же позволяет получать SMS или e-mail с короткими командами.
Пока вебморда только в нашем облаке. Понятно, что локально удобнее, но пока только так. Телефон/планшет подрубить можно локально.
Ну я просто размышлял как сделал бы я. Как противник разных сторонних сервисов, которые в любой момент могут начать диктовать свои условия, которые могут допустить утечку данных и т.п.
Локальный сервер с белым IP или DynDNS, который управляет системой и имеет некую API (SOUP, Rest или пропертиарную, как было у нас в микроядре). А дальше или мобильное приложение или вебморда на этом же сервере.
У нас не было вебморды, но у нас было немного сложнее — несколько типов различных интерфейсных клиентов как универсальный, так и специализированные, они подключались к микроядру, включающему в себя TCP сервер, и обменивались с ним командами в виде датаграмм.
Я как раз занимался разработкой микроядра. От архитектуры и протоколов до конечного кода. И был у меня технический клиент, который позволял видеть все, что там происходит на уровне кода (трейслоги) как в реальном времени, так и историю за последние 72 часа. Благодяря чему всегда мог ответить на вопрос типа «а что за фигня у них там на диспетчерской вчера в три часа ночи случилась?»
Локальный сервер с белым IP или DynDNS, который управляет системой и имеет некую API (SOUP, Rest или пропертиарную, как было у нас в микроядре). А дальше или мобильное приложение или вебморда на этом же сервере.
У нас не было вебморды, но у нас было немного сложнее — несколько типов различных интерфейсных клиентов как универсальный, так и специализированные, они подключались к микроядру, включающему в себя TCP сервер, и обменивались с ним командами в виде датаграмм.
Я как раз занимался разработкой микроядра. От архитектуры и протоколов до конечного кода. И был у меня технический клиент, который позволял видеть все, что там происходит на уровне кода (трейслоги) как в реальном времени, так и историю за последние 72 часа. Благодяря чему всегда мог ответить на вопрос типа «а что за фигня у них там на диспетчерской вчера в три часа ночи случилась?»
docker бы запекли для пробы на рабочей машинке
Так а чем это лучше раскрученных homeassist или openhab? Они тоже с различными устройствами умеют работать.
Что касаетя гибкости, то node-red позволяет подрубить к нему вообще практически всё от zigbee до rs485, а добавив туда mqtt можно подключить любой из десятков дашбордов из аппсторов.
Чем планируете их побеждать на рынке? :)
Когда я начинал работу над проектом что первый что второй были очень слабыми. Настраивать их только с бубном — в статье на это есть намек. Часовые видео на ютубе о подключении какой-то железки тоже не просто так выкладывают. Я же хотел сделать приложение более дружелюбнее к неподготовленному пользователю. Работы в этом направлении конечно еще много, но главная идеология такая и мы будем стремится ее реализовать в полном объеме. Побеждать их не планируем, это отличные проекты и у каждого из нас будет свой пользователь.
Лет 5 назад я пытался писать свой софт для умного дома, но у меня было оправдание — на рынке были только ужасные решения, вроде OpenHAB.
Я так потратил зря 2 года, и в итоге, разумеется, отказался от самописного велосипеда. Потому что сотни контрибьюторов Home Assistant развивают приложение гораздо быстрее и качественнее меня одного (или вас троих).
Вы уже очень далеко зашли в своём проекте, который все забудут года через 3, так что мне поздно уже советовать вам помогать сообществу писать интеграции в HASS. Это чтобы не нужно было смотреть потом часовые видео по настройке. Могли бы и продавать потом железки с HASS, оказывать платную поддержку точно так же, как со своим велосипедом.
Думаю, что вас ждёт печальная судьба вот этого проекта
habr.com/ru/post/382177
Я так потратил зря 2 года, и в итоге, разумеется, отказался от самописного велосипеда. Потому что сотни контрибьюторов Home Assistant развивают приложение гораздо быстрее и качественнее меня одного (или вас троих).
Вы уже очень далеко зашли в своём проекте, который все забудут года через 3, так что мне поздно уже советовать вам помогать сообществу писать интеграции в HASS. Это чтобы не нужно было смотреть потом часовые видео по настройке. Могли бы и продавать потом железки с HASS, оказывать платную поддержку точно так же, как со своим велосипедом.
Думаю, что вас ждёт печальная судьба вот этого проекта
habr.com/ru/post/382177
Энергопотребление в кВт/ч, серьезно? Интересно, когда-нибудь это закончится.
Ладно, не будем о грустном, вопрос.
Планируется ли интеграция с Samsung Smart Things?
Ладно, не будем о грустном, вопрос.
Планируется ли интеграция с Samsung Smart Things?
Не понял вашего сарказма. Энергопотребление в чем то другом измеряется?
Интеграция планируется с тем, на что будет спрос.
Конечно в другом, взгляните на счетчик.
Энергопотребление измеряется в кВт * час, но никак не в кВт/час.
Энергопотребление измеряется в кВт * час, но никак не в кВт/час.
Исправлю, спасибо.
Насчет SmartThings, спрос есть и даже с возможностью монетизации.
Там наблюдается следующая проблема. Есть экосистема с устройствами и относительно нормальным приложением, но вот чего нет — это приложения или сервера, который бы отдавал дашбоард. Нужно это, чтобы разместить по дому что-то типа дешевых планшетов, которые бы показывали информацию и давали возможность чтем-то управлять.
У вас, судя по картинкам это и реализованно, причем выглядит очень красиво. Если бы вы добавили интеграцию с существующими системами умного дома, то автоматически получили бы доступ к огромному количеству уже установленных систем.
Есть подобные системы, например ActionTiles но выглядят они очень плохо.
Там наблюдается следующая проблема. Есть экосистема с устройствами и относительно нормальным приложением, но вот чего нет — это приложения или сервера, который бы отдавал дашбоард. Нужно это, чтобы разместить по дому что-то типа дешевых планшетов, которые бы показывали информацию и давали возможность чтем-то управлять.
У вас, судя по картинкам это и реализованно, причем выглядит очень красиво. Если бы вы добавили интеграцию с существующими системами умного дома, то автоматически получили бы доступ к огромному количеству уже установленных систем.
Есть подобные системы, например ActionTiles но выглядят они очень плохо.
Я имел ввиду спрос именно в нашем приложении. Хороших систем много и мы конечно хотели бы поддержать их все. Но в статье есть заметка по этому поводу — на данный момент мы не располагаем достаточными ресурсами для реализации всех систем.
Я посмотрел, он поддерживается проектом zigbee2mqtt, а он поддерживается у нас, только стик с zigbee 3 нужен. Ну и шаблоны прописать в нашем приложении. Если есть желание и можете помочь, то мы сможем реализовать поддержку не имея оборудования для тестов.
Там не все устройства ZigBee, есть еще Z-Wave. Да и потом стик же куда-то вставлять нужно. Samsung позволяет сторонним приложения подключиться прямо к аккаунту клиента и тогда все измерения доступны прямо оттуда, не надо насчет интеграции с устройствами вообще думать. Так работают ActionTiles и SharpTools.
Есть еще открытый проект HousePanel тоже как-то достает данные напрямую из аккаунта.
Есть еще открытый проект HousePanel тоже как-то достает данные напрямую из аккаунта.
Классно все делаете. Жить в «Умном доме» не планирую, но проект всячески поддерживаю.
UFO just landed and posted this here
А как же Blynk? Бесплатный сервер, простая логика, отличный интерфейс клиента, простой и удобный, не такой детальный как у вас, но если не городить из квартиры центр управления полётами, вполне достаточно. Кстати, как вы считаете потребление электроэнергии по каждому прибору (интересует аппаратная часть)?
Когда я начинал Blynk только только появился. Это совсем другого рода софт — больше для diy.
Считаю по разному, в щитке стоит WB-MAP12H от WirenBoard, в розетках подрозеточные модули Shelly/Fibaro/Xiaomi. Они с учетом энергопотребления. Самый топ Fibaro из подрозетников, считает отдельно по 2 каналам, но всего до 10А.
Считаю по разному, в щитке стоит WB-MAP12H от WirenBoard, в розетках подрозеточные модули Shelly/Fibaro/Xiaomi. Они с учетом энергопотребления. Самый топ Fibaro из подрозетников, считает отдельно по 2 каналам, но всего до 10А.
А чем это лучше HomeAssistant?
Выглядит очень круто, гораздо лучше чем, то что есть отдельно у Яндекса или Xiaomi, что только со своими устройствами может работать. Попробую и может напишу отзыв.
augap а Tion разрешил вам вклиниваться в их протокол и тиражировать это? о_О
Или у них где-то API есть, которое можно официально использовать коммерческим решениям?
Желаю вам всяческого развития и процветания!)
Если бы взяли идеи и практики из Iobroker (количество драйверов, гибкость, телеграмм и т.д.), добавили Pro-mode в виде скриптов на какие-то «замороченные» события и логику (для DIYщиков), сделали некий «магазин» или просто «библиотеку» скриптов, добавили возможность делать кастомный HMI (Iridium)… Я бы за это заплатил!
Iobroker страдает, как по мне, отсутствием мануалов\гайдов на российском пространстве, но при этом очень гибок. Вы могли бы занять хорошую нишу устройства для интеграции «всего-в-одно». Жду когда кто-то наладит выпуск производительного мини-пк с HMI из коробки но при этом будет давать широкие возможности по интеграции (не вендор-лок) и глубокого кастомайзинга для DIY.
Если бы взяли идеи и практики из Iobroker (количество драйверов, гибкость, телеграмм и т.д.), добавили Pro-mode в виде скриптов на какие-то «замороченные» события и логику (для DIYщиков), сделали некий «магазин» или просто «библиотеку» скриптов, добавили возможность делать кастомный HMI (Iridium)… Я бы за это заплатил!
Iobroker страдает, как по мне, отсутствием мануалов\гайдов на российском пространстве, но при этом очень гибок. Вы могли бы занять хорошую нишу устройства для интеграции «всего-в-одно». Жду когда кто-то наладит выпуск производительного мини-пк с HMI из коробки но при этом будет давать широкие возможности по интеграции (не вендор-лок) и глубокого кастомайзинга для DIY.
Sign up to leave a comment.
Как построить “Умный дом" и не сойти с ума