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

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

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

 

В принципе да. Но подобный подход может негативно сказаться разве что там, где надо отслеживать быстрые процессы - например при нажатии кнопочного выключателя. Именно это имел ввиду @lingvo, говоря о modbus. Но он вообще сторонник Z-wave. Лично мне Ваш "проводной" подход куда более симпатичен.

Это как? У RS-485 довольно небольшая полоса пропускания. И если Вы установите поллинг небольшим (что необходимо для отслеживания кратковременных событий), то рано или поздно упретесь в эту полосу наращивая число устройств на одной шине. Если на практике - я сталкивался с тем, о чем говорит @lingvo, когда нажатие на кнопку не успевает считаться и приходится жать несколько раз или держать ее чуть дольше нажатой. Решение простое - под такие критичные устройства отдельная шина, минимальный поллинг и не более 2-3 устройств. Тогда все хорошо.

Я, кстати, на WB5 уперся в его производительность. При этом основной пожиратель как раз не поллинг, а логика со скриптами.

Ну вот представьте такой вполне реальный сценарий... Купил я у Вас изделия... И через некоторое время пришел к тому, что меня не устраивает производительность/интерфейс/возможности логики/возможности интеграции с чем либо еще... Какие действия возможны? Подключить то что есть к системе более высокого уровня (OpenHAB, ioBroker) - нет возможности. Выбросить Ваш сервер и оставить хотя бы периферию (уже плюс был бы -хотя бы не пришлось нести доп. расходы на оборудование и не заниматься переключениями) - тоже никак... останется выбросить все скрипя сердцем и делать заново. Я это проходил на Inels, которая вообще-то поинтереснее по возможностям, чем то, что предлагаете Вы, тем не менее была выброшена. Шлюз Modbus отчасти снимает вопрос, но он будет стоить денег и наверняка сопоставимых со стоимостью Вашего сервера... Ну и зачем все это надо? В результате куча сложностей, дороже и не факт, что удобнее в части логики... Я уж не говорю, что есть вполне обоснованное опасение, что все это будет глючным (как всякое новое и нестандартное) и иметь плохую поддержку от производителя. К слову, решение wirenboard тоже далеко не идеальное, но по опыту могу сказать - на их форуме очень неплохо осуществляется именно поддержка. Что проверено собственным опытом. В Вашем случае это может быть в виде писем "на деревню дедушке". Форума нет, как идет работа с пользователями не видно.

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

 

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

В WB для логики, как Вы наверное знаете, используется javascript - подобный язык. Вначале я это дело использовал, но вскоре (как я уже говорил) уперся в производительность. В итоге сейчас на WB остались скрипты, отвечающие только за особо ответственные задачи вроде системы безопасности. Все остальное отправилось в ioBroker, где используется также javascript - подобный язык, но со своими особенностями. При этом там есть возможность выстраивать логику объектно-ориентировано, но мне такой подход показался неудобным и громоздким.

Как работающий пример - вентиляция. Если коротко... Имеем 3 двигателя. Один (с двумя уровнями производительности) - приток + 2 вытяжки (кухня и ванная). Датчики - СО2, газа на кухне и балконе (этот на курение), влажности в ванной. Кроме этого, еще датчик на окне балкона и там же клапан отвода от вентиляции (для продува если накурено и окно закрыто). Есть еще термодатчик на притоке для регулирования уровня нагрева. Все это работает единым комплексом в зависимости от состояния датчиков. Там же реализована защита на случай возгораний (блокирование двигателей на случай высоких показаний датчиков и оповещение), полное проветривание в отсутствие людей и тп... В скрипте это около 100 строк. В Вашем варианте это было бы либо невозможно, либо очень громоздко. И как сказалось бы на производительности Вашего сервера - тоже большой вопрос. К слову, в Inels с их "user-friendly" интерфейсом я бы упарился сделать подобное...

 

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

@gonzzzales, предоставьте таким, как @Adavt, возможность писать скрипты и он от вас отстанет. Но возможность легкого составления правил не убирайте.

 

Уговорили Кстати, в WB5 есть поддержка CAN, но я не помню чтобы этим кто-нибудь интересовался на их форуме.

А почему не ESP + MQTT? Для бюджетной системы интереснее радиоканал... По собственному опыту - ESP может работать вполне стабильно. У меня есть примеры где ESP работает вообще без сбоев и есть где время от времени зависания и перегрузки. Но тут похоже проблема в софте, а не железе... Зато такое уже оформленное решение разлеталось бы как горячие пирожки, причем для совершенно различных систем и применений.

А вот это было бы правильное решение В том же ioBroker есть широкое разнообразие как это делать... вплоть до использования NodeRed, кому это привычно.

 

Ну никто так же не интересуется проприетарными протоколами на RS485. Потому, что тот, кто его использует, тот имеет уже свое железо.

Я думаю, что во-первых, вы готовы смириться с зависаниями и перезагрузками, а простой пользователь, купивший готовый продукт - нет. То есть будут накапливаться претензии к производителю, а он сам не знает причины. Это достаточно плохая ситуация с плохими последствиями.
Во-вторых с точки зрения MQTT интересен вариант проводного Ethernetа с PoE. Поставил где-нибудь свитч, да развел витую пару по всем местам без исключений. Я бы еще подумал о чем-то наподобие EtherCAT, чтобы можно было цеплять модули на одну шину один за другим и иметь гибкую топологию без ограничений по скорости. Кому надо - вариант с Wi-Fi.

 

Это Ваши домыслы. На WB5 есть поддержка подобного. Например - Uniel. И я и много кто еще активно интересовались. Особенно в связи с кое-какими проблемами. Еще - поддержка российских счетчиков ЭЭ. Мне это не интересно, но вижу, что спрос и интерес на это есть. Кстати, Uniel - очень неплохое решение для управления освещением, но все портит их протокол. Ладно бы они его держали бы закрытым и использовали в своих решениях, так нет - решений таких нет, он открытый... лучше бы реализовали modbus.

Я не готов. Это был у меня скорее пробный вариант. То, что из критичного до сих пор висит на ESP - СО2 датчик. Больше года отработал, но я все же планирую замену на другой с modbus (уже есть и работает, осталось впихнуть в корпус). При этом я вижу, что вполне эти проблемы можно решить на стороне разработчика софта. Становится разработчиком у меня желания нет.

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

 

Он не наш клиент вообще), человек которого раздражает программирование, но скрипты у него написаны, модбас настроен, больше 100 скриптов в WB). Но зато "я не смотрел скрины, мне не интересно", с вами и так все понятно "В Вашем варианте это было бы либо невозможно, либо очень громоздко". Удивляет, как люди, еще ничего толком не узнавшие начинают все критиковать только потому, что тут не так как у них!

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

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

При доскональном изучении CAN оказалось, что по сути это тот же самый RS-485 интерфейс с одним различием, у чистого 485 либо говорим либо слушаем, а у CAN - одновременно можно говорить и слушать, что сказал, если не совпало, значит коллизия. Но для чистого CAN-протокола нужно кроме трансмиттера ставить еще микруху самого протокола. В общем гемороя много, а толку мало - мы решили пока не брать can, но в принципе, перейти на CAN-подобный протокол можем.

 

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

 

Ну вот все переврали... не 100 скриптов и не в WB... а 100 строчек в скрипте на решение конкретной задачи и в ioBroker.

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

А вот это утверждение просто смешно... К слову, я бы и WB не стал бы позиционировать как "развитое решение для умного дома". Это всего лишь продвинутый контроллер, хотя и умеет куда больше Вашего... Тут Ваше решение я бы позиционировал для мелкой и ограниченной автоматизации домашнего хозяйства силами пользователя уровня домохозяйки без возможности расширения и использования как составной части более развитых систем (с голосовым управлением, работой с камерами, разнообразием оповещений, гибкой логикой и тп). Вот, скажем, простой пример - есть у Вас возможность управлять вентиляцией через датчики CO2 и газа? Предложите использовать еще не существующий modbus шлюз и стандартные IO устройства? Ну и зачем тогда все эти аппаратные костыли Вашего решения? Ради движка с логикой? Удобство которого тоже вызывает сомнения... Да даже функция управления светом - тоже вызывает ряд вопросов. На какой ток рассчитаны Ваши диммеры для LED? Сомневаюсь, что на 10 ампер (к слову - можно только догадываться, у Вас на сайте вообще нет ни слова о характеристиках нагрузки)... и что мне делать, если у меня есть такие светильники?

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

 

Ну Вы просто выслушиваете критический отзыв о системе.
По моему это хорошо, что ее критикуют. Черпайте от сюда информацию.

Ну а теперь что хотел добавить...
Бюджетная система (из коробки) вероятно найдет свою нишу. Но подумайте на сколько может "удорожать" (специально в кавычках ибо уверен, что удорожания системы в целом не произойдет) система от использования стандартного и популярного протокола? Тем более для домашней автоматизации.

Предположим загородный дом. Хозяин решил чего либо автоматизировать.
Внимание вопрос: Какие коммуникации у него уже могут быть?
Скорее всего небольшая локальная сеть. Сегодня гигабитный (неуправляемый) коммутатор продают за копейки! Да и коммутатор скорее всего уже есть в доме.
Протокол... Какой популярный и набирающий обороты? Тот же MQTT очень хорошо подходит для решения задач автоматизации дома. Вот беда... периферия только появляться начала с поддержкой этого протокола.
Брокер на чем поставить? RPi3 стоит копейки!
И даже если нет ни каких проводов в доме. Неужели есть разница что проводить UTP (которую кстати еще сын будет для учебы использовать) или провода для RS485? А еще в доме уже как правило есть покрытие wifi.
Чипы eth/wifi дорогие?

Бюджетно не значит медленно.
Использование стандартных "кирпичиков" в проекте может очень быстро подогреть интерес к нему как со стороны как рядовых покупателей так и "продвинутых".

И как тут уже говорили, оставьте возможность простой и визуальной настройки но и дайте возможность тонкой настройки с программированием своих алгоритмов.

зы. Написал. Почитал и подумал. Так есть же уже такое - бюджетное. Rpi3 + OpenHAB. Но вот с периферией (читай модули i/o) с поддержкой набирающего популярность протокола mqtt - пока не густо.

 

Обычный Ethernet не достаточно разве для дома? Не уж-то гигабита не хватит для автоматики?
Ну выделить модули в отдельный vlan и делов. Ни кому не мешают и им никто не мешает.

 

Практически полностью согласен со всем, что Вы сказали. Разве что можно еще дешевле Пробовал Orange PI Zero + ioBroker. Прекрасно работало. И стоимость платки около 10$. Отказался от такого решения в пользу виртуальной машины чисто из удобства создания снапшотов/резервных копий. Благо ESXi сервер есть в наличии и к тому резервирован надолго по питанию. В остальном - платка за 10$ показывала чудеса стабильности

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

 

Ну как бы тянуть от каждого модуля кабель к свичу не очень-то удобно - надо много кабелей. Особенно будет обидно, когда надо будет добавить пару модулей в полуметре от старых. Тут топология Ethernetа не очень проходит.

 

Таймеры не указали. Зимой отключается насос ГВС и котлы переходят в режим отопления. С отключением насоса ГВС сразу же включаются насосы ТП и Радиаторного отополения. Летом насос ГВС отключается с задержкой после того как отключился котел. Иначе в рубашке котла закипит теплоноситель. Нельзя отключить котел и сразу же прекратить циркуляцию в рубашке.

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

OpenHAB + RPi + MQTT