РЕКЛАМА НА ФОРУМХАУС Буду, если от общения тут будет какая-то польза, а не только рассказы, почему ничего не выйдет. Если тут столько супер-специалистов по умному дому, то было бы интересно услышать, например, какие более-менее открытые протоколы c открытыми же библиотеками есть смысл использовать по проводной шине, чтобы это было максимально совместимо с уже имеющимися на рынке модулями, или хотя-бы с какими-то семействами. Тот же LanDrive2 на Modbus RTU, как я понимаю, не является общим стандартом. Под Modbus есть библиотеки много под какие микроконтроллеры, но вот других модулей под него не густо. А хотелось бы иметь возможность стыковки своих модулей с другими производителями, не всё же самому делать. Либо как обычно решается стыковка различных протоколов? Есть ли какие-нибудь распространенные общие протоколы, с которыми стыкуются многие производители оборудования для умного дома?
Антон, библиотек под стандартные протоколы практически нет. Я занимался проработкой этого вопроса и сейчас постоянно отслеживаю что нового появилось. Библиотеки Modbus RTU и TCP представлены достаточно хорошо и хорошо подойдут для диспетчеризации инженерных систем в доме, но для оперативного управления (например освещением) этот протокол врядли пойдет, т. к. будет большая пауза между нажатием на клавишу и включением нагрузки и чем больше узлов в системе тем пауза будет больше. Кроме того, отказ мастера приведёт к отказу всей системы. Здесь видимо предпочтительно использовать протокол для децентрализованных систем, типа KNX, Lonwork и т. д. Нашёл пару библиотек по KNX, но похоже часть стека реализована на адаптерах сети EIB которые я не могу приобрести. Для себя я писал свой протокол а для визуализации делал конвертор в Modbus RTU (можно попробовать в Modbus TCP). Дальше стандартно - сервер с OPC и SCADA. PS Сейчас хочу кое что поменять в визуализации, неверно откажусь от сервера со СКАДОЙ о перейду на ТАЧ панели WiFi сервер.
Ура, еще полезности! Интересное замечание, кстати, какое время реакции считается приемлемым? И про сколько узлов речь? При запланированной мной гибридной схеме с несколькими центрами узлов вряд-ли будет больше десятка, да и взаимодействие между центрами будет минимальным, так как клавиши будут висеть на том же центре, что и силовой модуль управления освещением. А прямой запрос через центральный узел всегда можно поставить в приоритет. Однако вопросы скорости реакции на события от соседнего центра тоже интересны. Опять же, у меня в запланированной схеме всё просто станет работать как обычный "не умный" дом, каждый центр сам по себе автономен в базовом смысле (типа управления светом клавишами), по крайней мере уже сейчас понятно, как это сделать по освещению. Отрубится только веб-морда, через которую можно управлять "всем". Как я понял поверх RS485 есть децентрализованный Modbus Plus, но он проприетарный и не прост в исполнении. А свой протокол вы на основании какого-то известного писали (копируя оттуда приемы) или вообще с нуля? Я пока на OpenHAB рассчитываю в этом плане.
Антон, что касается времени реакции, ModbusRTU у себя использовал только в качестве шлюза Modbus -"свой протокол". В этом случае ардуино слев была подключена к ОРС мастеру по usb, а по 485 к слейву была подключена моя сеть. Ни каких вычислений в цикле опроса слейва не велось и всё происходило довольно быстро (не мгновенно). Время будет складываться на программном уровне из настроек в ОРС времени опроса, таймаута и количества повторения запросов в случае неудачи, их придётся настраивать под параметры конкретной сети. На физическом уровне выглядит так - перед отправкой команды на мастере в MAX485 надо поднять ногу разрешения передачи, подождать пока включится (в стандартном модбасе не помню сколько, помоему от 2 до 5милисек), затем передаётся команда затем опять пауза и передатчик отключается. То же самое на слейве, т. е. четыре паузы на опрос одной переменной плюс время на передачу. На ModbusTCP при подключении двух слейвов (порядка 40 переменных) исполнение команд иногда приходилось ждать порядка 5 сек. Для диспетчеризации нормально, для оперативного управления нет. То что в узлах все вычисления будут выноситься за цикл опроса это верно, но если вы хотите включить лампочку с одного контроллера с первого этажа на втором (с другим контроллером) то время выполнения команды будет заметным. На работе преобладает LonWorks, что немного отразилось на моём протоколе. Контроллеры обмениваются телеграммами типа: 01DO1S100.00 (KS) (записать в контроллера с адресом 01 в DO1 величину 1) в ответ приходит: 01DO1R100.00 (KS) - подтверждение выполнения команды. Все сообщения содержат одинаковое количество байт и тем самым упрощается их обработка. Можно передать аналоговую величину, запросить состояние, сконфигурировать выход и раздать адрес по сети. Для борьбы с коллизиями использую задержку передачи если линия занята и повтор команды до 10 раз если не приходит ожидаемый ответ.
@Anton66, прежде чем обвинять незнакомых людей в адекватности, а потом искать: Неплохо бы для начала прочитать культовую книжку "Маркетинг-менеджмент" Ф. Котлера. Разработка любого устройства ведется всегда исключительно от потребностей клиента и при разработке учитываются потребности инженера-установщика. Цена изделия при этом не играет большого значения. KNX удовлетворяет потребности обеих групп на 100% - клиента дизайном и функционалом, инженера-установщика простотой настройки, проектирования и устновки. Ваши "коробочки" не удовлетворяют ни одной потребности, т. к. являются изделиями для гиков и да же инженерам-элктронщикам они не будут интересны.
@Anton66, если вы сделаете аналог Mimi мне кажется все будет ОК. Вообще далек от электроники. Но то что увидел их сайте и на ютабе внушает что можно самому постепенно систему увеличивать. под свои потребности
Скажите, а писать бесполезные сообщения где-то учат? Нет бы назвать хоть парочку потребностей клиента, которым должны удовлетворять изделия, хоть какой-то смысл появился бы в ваших посланиях. И я всё-таки на секундочку обращу ваше внимание - я пока не планирую на этом зарабатывать, пока просто хочу решить задачу для себя. Если решение выйдет интересным - можно будет попробовать превратить его в коммерческий продукт. Путь это не быстрый. Может на этом пути и концепция поменяется, я пока не знаю. Может быть на этом пути промежуточные результаты могут оказаться полезны/интересны гикам, которые захотят их купить. PS: Знаете в чем отличие человека, реально разбирающегося в какой-то теме от человека, который усиленно делает вид, что разбирается в этой теме? Первый легко объяснит простыми словами суть любой проблемы или решения не очень знакомому с темой человеку, а второй будет сыпать умными терминами, ссылками на всякие труды, но так и не сможет ничего объяснить.
Кстати, интересный момент, может кто в теме? Есть ли какие-то реальные преимущества разбрасывания диммеров и прочих силовых модулей по всему дому в распределительные коробки, или это следствие того, что умный дом часто ставят тогда, когда отделку разносить уже нежелательно для прокладки новых линий до щитка?
У них вроде модули предполагают разбрасывание по всему дому, а не сбор всего в нескольких щитках? Или я что-то упустил?
Я так понимаю что можно либо сделать длинную шлейф от CAN шины (что видимо дешевле) либо уже обычный провод тащить до модулей. Видимо можно использовать только CAN шины для соединения управляющих модулей а силовая проводка будет идти только к потребителям.
У каждого свои потребности. У каждого свои возможности. У каждого свои интересы. @Anton66 делайте и флаг Вам в руки. По мне 25 тыр, тоже дорого, если я сам могу сделать устройство под себя. Планирую строить систему "Умный дом" в своём понимании и под свои задачи. Структурная схема - МАСТЕР - СЛЭЙВы. Хост по мере необходимости опрашивает все СЛЭЙВы и отображает результаты на своём мониторе. К Хосту можно подключить ПК. В качестве интерфейса, выбрал RS-485. Способы реализации возможны различны: 4-проводная (полный дуплекс), 2-проводная (Симплекс), кольцевая (полный дуплекс), пока не определился. На каждое перефирийное устройство свой микроконтроллер (СЛЭЙВ), который занимается обслуживанием этого устройства и обеспечивает связь с Мастером. Сам буду делать на Silabs микроконтроллерах, считаю, что их возможности вполне обеспечать необходимые параметры. Про Arduino, ничего сказать не могу (почитал и понял, что мне это не нужно), но для очень многих приложений вполне достойная архитектура. Для "Умного дома" вполне подходящая.
@vit54, вы вот эту тему почитайте: Умный дом на шине CAN Если у вас в планах нет управления светом, то "мастер-слэйв" сойдет, хоть тот же Модбас возьмите, чтобы не изобретать велосипед. А вообще-то KNX, C-bus и VelBus - это не "мастер-слэйв", а "производитель-потребитель" (producer-consumer). И сделано это вследствие веских причин. Какие микроконтроллеры использовать - это дело вкуса. Кому чего нравится. Вообще-то любые сгодятся.
CAN шину использовать не хочу. А по RS-485 у меня большие наработки (на большие растояния с большими скоростями), которые я и хочу использовать.
Я вам не предлагаю использовать CAN. Я вам предлагаю прочитать обсуждение, чтобы не переписывать уже сказанное еще раз. Для УД не нужны ни скорости, ни расстояния, так что ваши наработки не пригодятся. KNX прекрасно работает на скорости 9600, а C-bus - на скорости 5000. Зато, в отличие от высокоскоростных шин, их можно прокладывать как угодно, с ответвлениями любой длины. И никаких терминаторов не нужно. Это называется "свободная топология", и вот именно это как раз очень нужно для УД, а вовсе не скорость.