Умный дом "Кластер"

РЕКЛАМА НА ФОРУМХАУС

Вот у меня есть свой контроллер, который в том числе умеет RS-485, а конечные устройства я делать не могу (нет времени), а на интеграцию с уже готовыми устройствам время бы нашлось

 

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

Это всего лишь физический уровень на котором базируются различные протоколы.

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

Используй Вы стандартные протоколы можно:
1. в случае поломки деваса легко найти замену
2. легко перейти на вашу систему если уже имеются модули i/o

Бесспорно это в Вашу пользу, но!
Цена автоматики складывается не только из цены конечного устройства, а в том числе и в стоимости владения в которую войдут: проектирование, разработка алгоритмов, пусконаладка, сопровождение, восстановление после сбоев/поломок и т. д. И когда все вместе посчитать, оказывается цена самих устройств не очень то и влияет на саму систему автоматизации. Т. е. ее доля не столь существенна, что бы сэкономить 10 т. р. получив "уникальное", неизвестное устройство.

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

Этим свойством обладают все системы. Нельзя это записать в преимущества.
И на ПЛК тоже не нужно прошивку переписывать. Достаточно добавить программныйй юнит в котором описать новую задачу.

Пример:
Отопление, ГВС, водоснабжение

1. Переключение котла в режим лето/зима в зависимости от температуры на улице. В режиме отопления имеется 2 контура. Контур радиаторов, контур теплых полов.
Контур теплых полов переключается при достижении температуры на улице ниже заданной.
Контур радиаторов подключается при достижении температуры на улице ниже заданной.
Включение/отключение контуров отопления происходит путем включения соответствующего циркуляционного насоса.
Если температура на улице выше заданных для контура теплых полов и радиаторов - перевод котла в режим "лето" при котором допускается только работа в режиме ГВС.
2. Переключение котла в режим ГВС/отопление и управление циркуляционными насосами.
При понижении температуры в бойлере ниже заданной - котел переходит в режим ГВС, отключает насосы отопления (если они были включены) и включает насос ГВС.
При достижении температуры воды в бойлере выше заданной, если в режиме зима - перевести котел в режим отопление, насос ГВС отключается, включаются соответствующие насосы отопления.
Если котел в режиме "лето" то при достижении заданной температуры в бойлере, отключить котел, а насос ГВС отключить через заданное время (дабы не перегревать рубашку котла)
3. Контроль давления в контуре теплоносителя. В случае выхода давления за заданные пределы:
- направить СМС на заданный номер
- направить емейл на заданный адрес
- используя API доступа к функциям телефонной станции (в частности asterisk) воспроизвести синтезируемую речь на все имеющиеся в доме телефоны в режиме интеркома (громкая связь) об ошибке и "что делать". Текст формируется динамически, затем синтезируется используя API Yandex. speechю
Таких точек контроля в доме на самом деле много. Включая датчики охраны. В общей сложности более 30.
Система предусматривает 10 сценариев (режимов работы системы. Теоретически неограниченно). В каждом сценарии (режиме) свои установки на температуру или на маску охранных датчиков. Скажем, когда все дома - нет необходимости включать полную охрану дома. Достаточно контролировать разбитие стекол на 1 и цокольном этажах. В режиме охрана - понятно полный контроль. В режиме ОхранаНаДолго - еще и ГВС нет необходимости греть, но зато полезно ближе к вечеру на некоторое время свет включать в доме имитируя присутствие. При этом в каждом режиме, каждый датчик настраивается на то какие действия необходимо сделать при сработке данного события:
- СМС, емейл, voice, и т. д.
Если сработал датчик охраны - добавляется еще одно действие - запрос снапшотов со всех камер видеонаблюдения и отправка их на емейл. Взаимодействие с системой видеонаблюдения - используя API видеорегистратора.

Вот пример. И это только очень маленькая часть. Полное описание будет на нескольких листах.

 

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

 

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

Да, полностью согласен. Но представьте себе заказчика, человека далекого от DIY, и дайте ему в руки OIpenHab, что он с ним будет делать? Вы кстати пока так и не пояснили, какая именно периферия Вас интересует?

Давайте не будем лукавить, когда Вы обращаетесь в "серьезную компанию", торгующую KNX-устройствами, Вам тоже придется заплатить и за проектирование и разработку алгоритмов и за пусконаладку и т. д. И это ничем не отличается от нашей системы, только ценник на порядок выше. Для наших клиентов, кому мы устанавливаем систему "под ключ" мы тоже делаем проект, техническую документацию и оказываем полное сопровождение, но мы понимаем, что не премиальный сегмент рынка не способен выложить за решение простых задач автоматизации от полумиллиона и выше. Опять же, мы, в отличие от других систем даем пользователю полную свободу - хочешь поменять алгоритмы - меняй! Сломал что-то, не можешь починить - откатись на бэкап или звони в поддержку, поможем.

 

С теми ПЛК, с которыми работал я так сделать было нельзя, но даже сама фраза "добавить программный юнит в систему" обычного человека повергнет в ступор.
Я понимаю, что мы с Вами общаемся на некотором "птичьем" языке и прекрасно друг друга понимаем, но как только Вы попытаетесь эти "простые вещи" донести до эксплуатанта системы, Вы увидите, что он перестанет Вас понимать еще на старте.
Проект "Кластер" реализовывается именно с такой миссией: сделать умный дом доступным, причем не решить отдельную "боль", как то охрана (человека обокрали), протечка (затопил соседей) а предоставить комплексное решение повседневных задач за разумные деньги

 

Сурово)
Но давайте разберемся
Заводим в системе переключатели
1. на два режима зима/лето
2. на три режима теплый пол\т.п.+радиаторы\ГВС

Пишем сценарии
1. "Теплый пол" - отключить насос радиаторов, отключить насос ГВС, включить насос т. п.
2. "Теплый пол + радиаторы" - включить насос радиаторов, отключить насос ГВС, включить насос т. п.
3. "ГВС" - отключить насосы отопления, включить насос ГВС.
4. "Все выключит" - все насосы выключены

Пишем правила
1. если Тулицы<Тпорога1 то Режим Зима, иначе Режим Лето
2. если Тулицы<Тпорога2 и Tгвс>ТпорогаГВС то Режим т. п.
3. если Тулицы<Тпорога3 и Tгвс>ТпорогаГВС то Режим т. п.+радиаторы
4. если Tгвс<ТпорогаГВС то режим "ГВС"
5. если Режим Зима и Режим т. п. и Tтп<ТпорогаТП то сценарий "Теплый пол"
6. если Режим Зима и Режим т. п. и Tтп>ТпорогаТП то сценарий "Выключить все"
6. если Режим Зима и Режим т. п+радиатор. и Tвоздуха<ТпорогаВоздуха то сценарий "Теплый пол+ радиатор"
7. если Режим Зима и Режим т. п+радиатор. и Tвоздуха>ТпорогаВоздуха то сценарий "Выключить все"
8. если Режим Зима и Режим ГВС то сценарий ГВС.

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

Да, система не умеет отправлять e-mail и синтезировать речь (в принципе дописать это не сложно, я подумаю), но сами понимаете, это будет работать только так, где есть интернет.

Точно также настраиваются и все остальные функции системы.

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

Да, пока это так, но приведите мне пример бюджетной системы, удовлетворяющей Ваши запросы? Посмотрите что устанавливают себе люди: NooLite - свой протокол, Xiaomi - свой протокол, Rubitek - свой протокол, и т. д. По большому счету пользователя не волнует протокол, его волнует функциональность и надежность. То что Вы описали на данный момент реализовано в протоколе KNX и поддерживается многими именитыми брендами (ABB, Siements и т. д.), но это не доступно обычному человеку, эти системы ОЧЕНЬ дорогие, за полмиллиона с Вами только начнут разговаривать.

 

Ровно до тех пор, пока не встает вопрос об использовании оборудования от разных производителей. Я тоже когда-то наступил на подобные грабли. В свое время был выбран Inels c проприетарным и закрытым протоколом CIB на основе 485. В итоге все это недешевое оборудование отправилось в помойку из-за того, что никуда, кроме как в собственных решениях, его использовать не получится.

Другой случай - Uniel. Там тоже свой протокол поверх 485. К счастью, открытый. Уже лучше, но тоже неудобно.

Исходя из такого опыта наступать на грабли вторично нет никакого желания. Я прекрасно понимаю зачем Вы так поступаете - стараетесь привязать покупателя к своим решениям, чтобы и дальше он вынуждено покупал Ваши решения. Иного объяснения такого решения не вижу. Что мешало использовать тот же modbus? Рассказы про то, что Ваш протокол более продвинутый, мультимастерный - не более, чем маркетинг. К тому же есть у меня сомнение, что использование единственной шины (к тому же низкопроизводительной) на все оборудование - хорошее решение.

 

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

@Adavt, ну не канает Modbus для всех задач в УД. Это писал я и это пишут вам разработчики систем управления. При определенном количестве узлов у вас появятся серьезные задержки, которые будут влиять на комфорт. Поэтому выбор @gonzzzales очевиден и понятен. Собственный протокол - по этому пути идут даже именитые производители - тот же Homematic, когда хотят получить бюджетное решение. Да, дополнительный плюс - привязка пользователя.

По поводу сценариев и правил - было бы неплохо если бы вы привели скриншоты из вашей среды согласно описанной вами логике. Я могу привести аналогичные скриншоты из Node-Red, а @Smith2007 из Codesys - можно будет посмотреть у кого легче читается.

 

Прекрасно это понимаю, но все равно спасибо!

Вообще мы не рассуждали, где лучше читается, речь шла о том, возможно сделать то, что описал @Smith2007, в системе. Я выложу скрины, как это оформлено в нашем конфигураторе, могу представить реакцию, что тот же Codesys окажется более наглядным, но это инженерный продукт, а не пользовательский, чтобы работать в Кодесисе нужно как минимум представлять логику работы МК, правила расстановки FB-блоков и составление связей между ними. Мы как раз ставили задачу максимально упростить работу с конфигуратором: никакого кода, никакой лишней информации, только то, что относится непосредственно к системе.
Скрины ниже

 

Меню программы. В ней всего несколько сущностей: любое действие или последовательность действий - это сценарий, любое условие - это правило, разветвление логики (зима/лето) удобно сделать виртуальными переключателями.

Вот интерфейс модуля управления, второй выход которого предназначен для датчика температуры и имеет название "Температура"

Настраиваю виртуальный переключатель Зима/лето

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

Создаю сценарий отопления теплым полом и радиатором из трех действий

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

Настраиваю правило, в нем два условия, если они оба выполнятся, сработает сценарий "теплый пол + радиаторы"

Условие 1

 

Условие 2

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

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

 

1. Modbus уже обсуждали. Я не испытываю никакого дискомфорта. Про количество узлов - верно. Но что мешает использовать несколько шин?

2. Выбор собственного modbus подобного протокола поверх того же 485 будет обладать ровно теми же недостатками, о которых Вы тут утверждаете. А то, что он более продвинут в части возможностей мультимастера говорит о том, что на одну шину хотят повесить вообще всю переферию. Ну и к чему это приведет согласно Ваших опасений? А если еще вспомнить про упомянутый механизм борьбы с коллизиями (подозреваю как в классическом Ethernet, что приведет к росту задержек в канале)? Вполне допускаю, что их самоделка действительно интереснее стандартного и древнего modbus. К примеру упомянутый мной CIB действительно удобнее, хотя бы тем, что по той же шине идет и питание на устройства и в результате шина выходит 2-проводной, а не
4-проводной (данные +питание). Но что с этим делать, если по каким-то причинам возникает желание использовать все это оборудование в другой системе?

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

 

https://clustersystem.ru/catalog/ все цены указаны

 

Спасибо! Это я пропустил...

Ну что я могу сказать... если сравнивать с "крутыми" игроками на рынке - то конечно, бюджетно. Ну а на мой взгляд - дороговато. К примеру, сервер управления 16500р - явно чрезмерно, сравните с российским wirenboard (который я также использую) - стоимость близкая, но последний куда интереснее... Реле одноканальное за 1000р - ну просто смех. К примеру, есть у меня китайский девайс, I/O modbus RTU+TCP - 8+8 дискретных входов и выходов, 16+4 аналоговых входов и выходов (причем конфигурируемых 0-10V или 4-20ma) - обошелся мне где-то в 4500р. При этом не "кот в мешке" с собственным протоколом, а вполне себе стандартный девайс на DIN рейку...

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

 

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

Допустим у вас 100 слейв-устройств, если у Вас один мастер в сети, то без разницы, одна шина, или две, поллинг всех устройств все равно будет съедать ресурсы мастера, а если у Вас на каждую шину еще и свой мастер, то нужно их как-то согласовывать, соответственно это тяжелее в разработке и дороже в производстве. Проблема будет не в канале, современные rs-485 трансмиттеры поддерживают большую скорость передачи и большое количество устройств на линии, а проблема в ресурсах МК Мастера, ему ведь надо не только поллингом заниматься, а еще и логику отрабатывать, вот тут-то и возникнут лаги.
И все это ради чего? Использовать Модбас чтобы иметь возможность подключения промышленного оборудования? Не проще ли сделать отдельный шлюз для него (чем мы сейчас и занимаемся).