Comments 56
Суть в том, что несмотря на обилие различных устройств, все они делают приблизительно одно и то же и предоставляют примерно одинаковую информацию. Поэтому все возможности устройств были вынесены в отдельные примеси, из которых в конечном итоге и состоит окончательный драйвер. Например, в приложении поддержано множество устройств, имеющих функцию включить/выключить. Она-то и вынесена в отдельную примесь и идентично используется для всех девайсов. Элементарно же, Ватсон!
В свое время занимался разработкой системы мониторинга инженерного оборудования зданий.
Там была совсем другая архитектура (распределенная система на микроядреной архитектуре). Общая суть такова — есть «контроллер верхнего уровня» — 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 протоколу, интерфейсные клиенты (там тоже был зоопарк — клиенты были общие, специализированные, могли получать всю информацию из системы или работать с ограниченными наборами устройств — всем этим, кому чего посылать, и рулило микроядро, кроме своей основной функции — реализации отношения «многие ко многим»).
В целом сложновато чтобы все описать вот так в одном комменте, но суть такая — постараться составить формальную классификацию устройств по принципу «класс + набор характерных признаков», сделать некоторый «сервер», который будет хранить конфигурацию системы и отслеживать ее текущее состояние (тут, боюсь, малинки может и нехватить) и, скажем, вебморду, на которой можно будет видеть и управлять всем хозяйством издаля.
Шишек набили, но многие архитектурные решения оказались удачными настолько что переносились из версии в версию. В частности, система драйверов устройств с универсальным интерфейсом (когда вся специфика внутри драйвера) и система классификации устройств (она расширялась по мере появления новых типов и классов, но основа осталась то, что была заложена в самом начале).
В настоящее время проект стремительно развивается, и вся наша команда старается предельно расширить перечень поддерживаемого оборудования, имеющегося на рынке. Хотя над проектом работаю уже не я один, задачи остались те же — создать максимально удобное приложение, которое учитывает пожелания и решает проблемы всех, кто занимался самостоятельной установкой смарт-решений для дома.
По моему опыту просто приложения будет мало. Нужен комплекс. Железо + софт. Причем, управление не на уровне «хлопнул в ладоши — свет зажегся», это все прикольно, но реальной пользы мало.
Интереснее, скажем, система управления климатом для частного дома. Т.е. температура-влажность. А это значит, что вы должны управлять отоплением, кондиционированием и вентиляцией. Причем, достаточно гибко. Не на какой-то конкретный котел, а иметь несколько схем.
Например, электроконвекторы по комнатам + теплый пол + вентиляция + конлдиционеры. Плюс возможность задавать расписание — когда дома никого нет (в рабочее время, например), можно понизить температуру и получить экономию энергии. А к приходу хозяев опять выйти на режим. Или понизить температуру в неиспользуемых помещениях (ночью в гостиной, к примеру), но к утру опять выйти на режим.
Если то же отопление завязано на электричество, неплохо бы контролировать пиковую мощность и обеспечить приоритет включения мощных потребителей (чтобы оставаться в пределах максимальной пиковой мощности). Скажем, для тех же конвекторов обеспечить их включение по группам, а не всех сразу.
И т.д. и т.п.
Плюс надежность и отказоустойчивость — если у вас упал сервер, основное оборудование (то же отопление) должно продолжать работать пусть и по неэффективным алгоритмам, но обеспечивать приемлемый уровень комфорта.
В общем, если к вопросу подойти серьезно, там очень много граблей разложено.
Нам пока просто софта более чем достаточно, т.к. оборудования на рынке итак уже много на любой вкус и цвет и мы можем подбирать под конкретный проект любое оборудование.
Отказоустойчивость софта достаточно высокая и мы продолжаем работать над ее улучшением.
Граблей за 3 года работы над проектом повидали немало.
Ну и в квартире я использую оборудование на климат у которых состояние не вкл/выкл, а поддержание заданных условиях, т.е. даже если все упадет, оборудование продолжит работать на заданных условиях.
А вот свои контроллеры на STM32 получились конкуретнтоспособны по цене и весьма надежны в работе. Плюс там была возможность модульной замены отдельных блоков и расширения блоками. Плюс мы в них закладывали то, что нам нужно и в результате могли подключать практически все, что управляется электричеством и имеет документированный протокол обмена.
А подключать приходилось много чего — лифтовые контроллеры (УБДЛ и еще какие-то другие), теплоэнергоконтроллеры (Карат, ТСТ, ТЭКОН...). Это не считая различных датчиков и исполнительных механизмов.
Ну у нас суть проекта как раз в том, что пользователь сам может подобрать оборудование, которое может себе позволить. Понятно, что качество этого железа будет отличаться, но появляется свобода выбора в рамках единой экосистемы. Мы тут не первые, на первенство не претендую если что.
Мы тоже так делали — все конечные устройства были клиента, мы тут ничего не диктовали. Мы предоставляли только свои контроллеры и софт. И подключали к ним уже то, что есть у клиента. Потому и пришли к классификации устройств и подгружаемым драйверам. Чтобы система была расширяема на ходу, причем, без ее остановки В наших условиях останавливать систему для обновления в случае появления у клиента нового устройства, которое мы заранее не предусмотрели, было неприемлимо. Например, для систем ЛДСС (лифтовая диспетчерская связь и сигнализация — одно из основных наших применений) есть ПУБЭЛ (правила установки и безопасной эксплуатации лифтов), по которым лифт не может эксплуатироваться если нет системы диспетчеризации. Т.е. остановка системы означает предварительную остановку всех подключенных лифтов. А потом их включение обратно. А их в системе может быть несколько сотен. И раскиданы они по всему городу (сейчас УК работают экстерриториально). Т.е. введение в систему любого нового типа устройства должно происходить без ее остановки, путем подключений нового драйвера.
Ну а классификация простых устройств через набор признаков вообще позволяла такие вещи как датчики охраной, пожарной сигнализации, протечек и прочего подключать просто сконфигурировав их набор свойств + текстовые описания самого датчика и его состояний. Такие простые вещи клиент вообще мог сам делать — подключить датчик к клеммам на УСО и описать его в софте.
Естественно, предусмотрена возможность отключения датчика (временная или постоянная) если он вдруг вышел из строя и начал генерить поток аварийных сообщений.
Плюс логирование всего и вся (включая записи разговоров диспетчера с кабинами лифтов).
У вас, видимо, уже более серьезная автоматизация под объекты жкх, так?
Там я конечно понимаю, что требования другие. Мы пока в этот рынок не смотрели особо, но об описанных Вами сложностях прекрасно понимаем. У нас домашняя автоматизация, но правила чуть сложнее устроены, чем у подобных проектов. В будущем мы будем расширять возможности, если это будет востребовано, включая и возможность работы нон-стоп.
Первые контроллеры у нас были на Intel 8080 и было две пары — голос и данные. Плюс софт на компе где была карта района с обслуживаемыми домами и выводидись сообщения от устройств. Ну и логирование всего что происходит.
Пилотный проект ставили под эгидой конторы, которая занималась обслуживанием лифтов. За деньги этой конторы при условии что она берет объект на обслуживание.
Это потом уже появились конкуренты (которые во многом копировали наши решения, по крайней мере в плане интерфейса точно).
Дальше уже развивались в более универсальную систему, которая может мониторить оборудование, распределенное в большом районе. Но ЛДСС оставалось одним из основных направлений работы.
На самом деле, принцип там один везде — есть некоторое устройство, обладающее собственной автоматикой (в нашем случае это теплоэнергоконтроллеры, система пожарной сигнализации и дымоудаления, лифтовые контроллеры...), есть каналы связи, позволяющие мониторить работу системы и есть возможность корректировать работу встроенной автоматики как в ручную, так и по заложенным алгоритмам.
Обязательно — система оповещения о критических ситуациях. Пожар, протечка воды, отключение электричества, выход параметров за пределы заданных режимов и т.п.
Включать/выключать вентиляторы через DO или AO (для EC вентиляторов)
Управлять водяным или электричесикм калорифером.
Принимать данные с датчиков.
Рассчитывать ПИД регулирование…
Т.е. делать всё то, что делают контроллеры автоматизации.
Спрашиваю, иббо меня не покидает желание для домашней системы вентиляции найти решение, совмещающее в «одном флаконе» и бэкенд, рулящий физическими средами и обрабатывающий датчики, и фронт-енд, рисующий GUI.
Всё, что нахоже — требуют программирования двух сущностей.
А разработчики GUI решений почему-то :) всегда считают, что есть уже КТО-ТО, запрограмировавщий контроллер вент.машины. И не не желают самим стать этим кем-то :)
Мы разрабатываем комплексное решение и заинтересованы в полноценном управлении)
Включать/выключать, снимать показания и делать под это дело правила уже умеем.
Если есть желание помочь, присоединяйтесь в телеграмм канале.
Таки лично мне проще поднять сервер на виртуалке, что бы попробовать, чем покупать оборудование для системы, которая может и не пригодится.
Но как установить сервер например на винду? На сайте дистрибутива нет.
И нескольк не понял — зачем в программе для андроид нужна регистрация?
Регистрация нужна для облачных функций. Использовать облако или нет по Вашему желанию, мы не навязываем.
Ну тут к сожалению мимо — в телеграмме не зарегистрирован и не планирую.
Как факт (Вы просили указать предложения) — это как минимум усложняет использование.
«Регистрация нужна для облачных функций.»
Но без регистрации использовать не получается, что тоже с моей точки зрения не правильно. Лично я ставить точно не буду, как другие не знаю.
Простейший пример — хочу с рабочего компа на работе этим всем управлять. Ну или хотя бы наблюдать. Одна беда — выход в инет на нем нет. Только внутренняя сеть (это требования УИБ, их не обойти). Но есть «безопасный браузер» (фактически, он стоит на другой машине, я вижу только картинку). Т.е. через браузер выйти в нет могу, но никакое другое приложение в с компа в сеть не попадет никак.
Вебморда сразу решит все эти проблемы. Не надо будет думать про разные операционки. Ну разве что мобильные приложения сделать как обертку для вебморды (ну или параллельный REST/SOAP API поддерживать для мобильных приложений). Как вариант — в основе REST API, доступ нему или через вебморду, или через мобильное приложение.
Все драйвера всех устройств работают на домашнем сервере. Управлять им через API. И не надо никаких облаков.
Сам сервер держит БД с конфигурацией и текущим состоянием системы. Он же опрашивает датчики, управляет механизмами по заданному расписанию (например, управление температурой в помещениях с целью экономии энергии — снижение температуры даже на 3 градуса когда дома никого нет уже ощутимо экномит энергозатарты на отопление). Он же посылает аварийные сообщения (SMS, e-mail) в случае ЧП (например, сработала пожарная сигнализация или датчик протечки). Он же позволяет получать SMS или e-mail с короткими командами.
Локальный сервер с белым IP или DynDNS, который управляет системой и имеет некую API (SOUP, Rest или пропертиарную, как было у нас в микроядре). А дальше или мобильное приложение или вебморда на этом же сервере.
У нас не было вебморды, но у нас было немного сложнее — несколько типов различных интерфейсных клиентов как универсальный, так и специализированные, они подключались к микроядру, включающему в себя TCP сервер, и обменивались с ним командами в виде датаграмм.
Я как раз занимался разработкой микроядра. От архитектуры и протоколов до конечного кода. И был у меня технический клиент, который позволял видеть все, что там происходит на уровне кода (трейслоги) как в реальном времени, так и историю за последние 72 часа. Благодяря чему всегда мог ответить на вопрос типа «а что за фигня у них там на диспетчерской вчера в три часа ночи случилась?»
Так а чем это лучше раскрученных homeassist или openhab? Они тоже с различными устройствами умеют работать.
Что касаетя гибкости, то node-red позволяет подрубить к нему вообще практически всё от zigbee до rs485, а добавив туда mqtt можно подключить любой из десятков дашбордов из аппсторов.
Чем планируете их побеждать на рынке? :)
Я так потратил зря 2 года, и в итоге, разумеется, отказался от самописного велосипеда. Потому что сотни контрибьюторов Home Assistant развивают приложение гораздо быстрее и качественнее меня одного (или вас троих).
Вы уже очень далеко зашли в своём проекте, который все забудут года через 3, так что мне поздно уже советовать вам помогать сообществу писать интеграции в HASS. Это чтобы не нужно было смотреть потом часовые видео по настройке. Могли бы и продавать потом железки с HASS, оказывать платную поддержку точно так же, как со своим велосипедом.
Думаю, что вас ждёт печальная судьба вот этого проекта
habr.com/ru/post/382177
Ладно, не будем о грустном, вопрос.
Планируется ли интеграция с Samsung Smart Things?
Не понял вашего сарказма. Энергопотребление в чем то другом измеряется?
Интеграция планируется с тем, на что будет спрос.
Энергопотребление измеряется в кВт * час, но никак не в кВт/час.
Исправлю, спасибо.
Там наблюдается следующая проблема. Есть экосистема с устройствами и относительно нормальным приложением, но вот чего нет — это приложения или сервера, который бы отдавал дашбоард. Нужно это, чтобы разместить по дому что-то типа дешевых планшетов, которые бы показывали информацию и давали возможность чтем-то управлять.
У вас, судя по картинкам это и реализованно, причем выглядит очень красиво. Если бы вы добавили интеграцию с существующими системами умного дома, то автоматически получили бы доступ к огромному количеству уже установленных систем.
Есть подобные системы, например ActionTiles но выглядят они очень плохо.
Я имел ввиду спрос именно в нашем приложении. Хороших систем много и мы конечно хотели бы поддержать их все. Но в статье есть заметка по этому поводу — на данный момент мы не располагаем достаточными ресурсами для реализации всех систем.
Я посмотрел, он поддерживается проектом zigbee2mqtt, а он поддерживается у нас, только стик с zigbee 3 нужен. Ну и шаблоны прописать в нашем приложении. Если есть желание и можете помочь, то мы сможем реализовать поддержку не имея оборудования для тестов.
Есть еще открытый проект HousePanel тоже как-то достает данные напрямую из аккаунта.
Считаю по разному, в щитке стоит WB-MAP12H от WirenBoard, в розетках подрозеточные модули Shelly/Fibaro/Xiaomi. Они с учетом энергопотребления. Самый топ Fibaro из подрозетников, считает отдельно по 2 каналам, но всего до 10А.
Если бы взяли идеи и практики из Iobroker (количество драйверов, гибкость, телеграмм и т.д.), добавили Pro-mode в виде скриптов на какие-то «замороченные» события и логику (для DIYщиков), сделали некий «магазин» или просто «библиотеку» скриптов, добавили возможность делать кастомный HMI (Iridium)… Я бы за это заплатил!
Iobroker страдает, как по мне, отсутствием мануалов\гайдов на российском пространстве, но при этом очень гибок. Вы могли бы занять хорошую нишу устройства для интеграции «всего-в-одно». Жду когда кто-то наладит выпуск производительного мини-пк с HMI из коробки но при этом будет давать широкие возможности по интеграции (не вендор-лок) и глубокого кастомайзинга для DIY.
Как построить “Умный дом" и не сойти с ума