Система Loxone
Руководство по системе Loxone: архитектура и применения
Как устроена система автоматизации зданий Loxone: Miniserver, модули расширения, Tree, Air и 1-Wire, программирование в Config, интеграция с KNX, BACnet и Modbus, а также реализация проектов.
Краткий ответ
Loxone — платформа автоматизации зданий с приоритетом локальной работы, построенная вокруг Miniserver — контроллера, который выполняет логику, расписания и сцены без обязательного подключения к облаку. Модули расширения добавляют входы и выходы, Tree, Air и 1-Wire подключают полевые устройства, а Config определяет поведение, которое предоставляют приложение и интерфейсы.
Архитектура с приоритетом локальной работы
Loxone построена вокруг простого принципа: здание должно продолжать работать, когда интернета нет. Miniserver хранит программу управления, выполняет расписания и сцены и обменивается данными с полевыми устройствами по локальным шинам. Удалённый доступ и мобильное приложение — удобные надстройки, а не зависимость для повседневной работы. Такое решение подходит зданиям с ненадёжной связью, строгими требованиями к хранению данных или необходимостью работать при сетевом сбое. Оно меняет и модель поддержки: интегратор может диагностировать логику на месте, а владелец не зависит от окончания подписки. Локальность не означает изоляцию. Шлюзы и интерфейсы подключают оборудование KNX, Modbus, DALI и BACnet, а диспетчер может считывать данные системы, не перехватывая управление. Для коммерческого здания тот же принцип относится к сети контроллеров: сначала локальная автономия, затем центральная координация. Практический вопрос — какие функции должны пережить отказ WAN и проверен ли этот сценарий в проекте. Заявление о локальной работе, которое никогда не проверялось в автономном режиме, — лишь рекламная фраза. Проверку следует повторять после обновления прошивки, поскольку изменение поведения контроллера может незаметно вернуть зависимость, которую проект устранил. Локальная автономия имеет и цену: каждому контроллеру нужны собственная резервная копия и собственный план замены.
- Логика и расписания хранятся на объекте
- Приложение и удалённый доступ как дополнительные уровни
- Локальные шины для полевых устройств
- Шлюзы для систем сторонних производителей
Miniserver и модули расширения
Miniserver — это базовый контроллер: он хранит программу, расписания, права пользователей и интерфейсы. Встроенные входы и выходы напрямую покрывают небольшую установку; модули расширения добавляют ёмкость через локальную шину по мере роста проекта. Планирование ёмкости должно выполняться до сборки шкафа, поскольку тип входов, тип выходов и резервная ёмкость влияют на корпус, блок питания и проводку. Проект должен также фиксировать, какие функции выполняются на каком контроллере, чтобы отказ имел ограниченные последствия. Резервные копии, лицензионные документы и проверенная процедура восстановления — часть системы, а не запоздалая мысль. Выбор модели — проектное решение, основанное на количестве точек, требованиях к интерфейсам и будущем расширении, а не вариант по умолчанию, повторённый из прошлого проекта. Выбранную модель следует документировать вместе с количеством точек и перечнем интерфейсов, которые её обосновали. Резерв ёмкости на этапе проектирования дешевле второго шкафа после передачи объекта, и его следует указывать в процентах от используемой ёмкости, а не оставлять расплывчатым намерением. Процедура замены должна быть написана для человека, который никогда не видел шкаф, и один раз проверена, пока исходный инженер ещё доступен. Второй контроллер для отказоустойчивости — проектное решение, а не вариант по умолчанию; для него нужно определить поведение при переключении.
- Программа, расписания и права доступа
- Встроенные I/O и шина расширения
- Планирование ёмкости и резерва
- Резервные копии и проверенное восстановление
Tree, Air и 1-Wire
Loxone использует три периферийные технологии для разных задач. Tree — проводная шина для выключателей, датчиков, диммеров и исполнительных механизмов; она передаёт питание и данные и подходит для новых объектов, где трассы кабелей запланированы. Air — беспроводной протокол для устройств, где прокладка кабеля нецелесообразна, включая модернизацию и некоторые места установки датчиков; он требует обследования сигнала и стратегии питания для устройств с батареями. 1-Wire — простая шина, используемая главным образом для измерения температуры в полах, трубах и помещениях, с адресацией, позволяющей идентифицировать каждый датчик. Все три могут сосуществовать в одной установке. Правила проектирования охватывают топологию, длину кабелей, оконцевание, бюджет питания и отделение от сетевых помех. Выбор определяется не тем, какая технология новее, а зданием, трассами и моделью обслуживания. Беспроводные решения следует рассматривать как проектное решение с планом обслуживания, а не как обходной путь вместо планирования. Документирование адресов устройств и топологии шин экономит часы при пусконаладке и последующем поиске неисправностей, и именно это теряется первым при передаче проекта между монтажниками. Беспроводное устройство, до которого нужно добираться по лестнице, создаёт затраты на обслуживание, даже когда оно не является проблемой управления. Маркировка каждого сегмента шины с обоих концов — небольшая привычка, которая экономит долгий день.
- Tree: проводная шина с питанием и данными
- Air: беспроводная связь для модернизации и датчиков
- 1-Wire: измерение температуры
- Документированные топология, питание и адресация
Config: программирование здания
Config — среда проектирования, в которой определяется поведение здания. Функциональные блоки обрабатывают входы, выходы, логику, расписания, сцены, тревоги и права пользователей. Хорошо структурированный проект использует соглашения об именовании, переиспользуемые блоки и комментарии, понятные другому инженеру. Моделирование и онлайн-тестирование помогают проверить логику до пусконаладки, но не заменяют поэлементную проверку на объекте. Важен контроль версий: изменённое расписание или новая блокировка должны регистрироваться с датой и причиной. Контроль доступа к файлу проекта тоже важен, поскольку недокументированное изменение может подорвать проверенный алгоритм. Результат Config — не только работающая программа, но и поддерживаемое описание того, как здание должно себя вести, что и нужно владельцу при передаче объекта. Соглашение об именовании, принятое в начале, дешевле переименования блоков после пусконаладки. Если единственный человек, способный прочитать программу, ушёл с проекта, здание потеряло часть документации. Программу следует рассматривать как управляемый документ, а не как личный блокнот. Программа, зависящая от недокументированных глобальных переменных, не поддаётся сопровождению, как бы элегантно ни выглядела логика на экране. Два инженера должны иметь возможность открыть её и найти один и тот же блок для одной и той же функции.
- Функциональные блоки для логики и алгоритмов
- Соглашения об именовании и переиспользуемые блоки
- Моделирование и поэлементная проверка на объекте
- Контроль версий и управляемый доступ
Интеграция с другими системами
Очень мало зданий обходится одним поставщиком. Loxone интегрируется через собственные интерфейсы и шлюзы: KNX для освещения и комнатных устройств, Modbus RTU или TCP для счётчиков, инверторов и оборудования, DALI для светильников, BACnet через шлюз для установок и диспетчерских систем, HTTP или REST для программных сервисов. Сухие контакты остаются надёжным резервом для пожарной сигнализации, устаревшего оборудования и простых сигналов состояния. Каждому интерфейсу нужна карта точек: адрес источника, имя в системе, тип данных, единица измерения, масштабирование, направление чтения или записи и состояние отказа. Шлюзы добавляют устройство, которое нужно запитать, настроить и задокументировать. Проект интеграции должен определять, что происходит при отключении шлюза и может ли локальный контроллер продолжать работу без него. Встроенная поддержка и поддержка через шлюз — разные обязательства; в спецификации следует указать, какая из них требуется для каждой системы. Для каждого интерфейса фиксируйте, кто отвечает за конфигурацию шлюза и кого вызывают при его отказе. Интерфейс, который работает сегодня, но не имеет ответственного, тихо откажет в следующем году. Состояние отказа следует определять для каждой точки, а не для шлюза в целом. Реестр интерфейсов полезнее схемы подключения, когда устройство стороннего производителя ведёт себя неправильно.
- KNX и DALI для освещения и управления помещениями
- Modbus для счётчиков и оборудования
- BACnet через шлюз для установок
- Карта точек с масштабированием и состояниями отказа
Планирование и ёмкость
Планирование проекта Loxone — в основном упражнение в подсчёте и определении границ. Начните с перечня точек, сгруппируйте точки по расположению и решите, какой контроллер обслуживает какую группу. Держите зону ответственности каждого контроллера достаточно узкой, чтобы отказ затрагивал одну зону или одну единицу оборудования, а не всё здание. Предусматривайте резервные I/O для будущих изменений; типичный планируемый резерв — 10–20 % используемой ёмкости, но решать должно собственное ожидание роста проекта. Проверяйте бюджет питания шины, длины кабелей и количество устройств на линию по документации производителя для конкретной модели и прошивки. Оставляйте место в шкафу для дополнительного модуля расширения и маркируйте резервные клеммы. Фиксируйте перечень интерфейсов с протоколом, моделью шлюза и количеством точек на каждом канале. План ёмкости, который не записан, — это догадка, а догадка, сделанная до сборки шкафа, становится ограничением на следующие десять лет. План должен также определять, что произойдёт при замене контроллера, потому что этот день наступит. Файл программы, лицензия и резервная копия должны храниться там, где их контролирует владелец, а не только на сервере интегратора. План ёмкости следует пересматривать при каждом проектном изменении, а не только в начале.
- Группируйте точки по расположению и границе отказа
- Типичный резерв 10–20 %
- Проверяйте питание шины, длину кабеля и количество устройств
- Фиксируйте план ёмкости и путь замены
Реализация и жизненный цикл
Проект Loxone выполняется поэтапно: требования, перечень точек, проектирование шкафа, конфигурирование, заводские испытания, пусконаладка на объекте, передача объекта и поддержка. Заводские испытания выявляют ошибки монтажа и конфигурации до того, как объект станет загруженным. Пусконаладка на объекте подтверждает каждую точку, каждый алгоритм и каждую тревогу, включая поведение при отключении устройства. Передача объекта должна включать резервные копии, схемы сети, учётные данные, руководство пользователя и обучение тех, кто будет эксплуатировать здание. Модель поддержки должна быть явной: кто реагирует, в каких пределах и как согласуются изменения. Систему с приоритетом локальной работы проще обслуживать, когда владелец располагает файлом проекта и документацией, а не зависит от ноутбука одного инженера. Планирование жизненного цикла должно также охватывать резервные устройства, обновления прошивки и процесс добавления нового этажа или арендатора. Владелец должен иметь возможность добавить устройство или изменить расписание, не перестраивая всю программу. В этом практический смысл открытой локальной системы. Сценарий пусконаладки должен включать перезапуск контроллера, отключение шинного устройства и отказ шлюза, потому что с этими условиями здание в конечном итоге столкнётся. Обучение должно включать работу с тревогами, а не только нажатие кнопки сцены. Первый год эксплуатации должен включать анализ фактически внесённых изменений, поскольку этот перечень показывает, используется ли система так, как задумано.
- Сначала требования и перечень точек
- Заводские испытания до работ на объекте
- Поэлементная пусконаладка
- Резервные копии, обучение и условия поддержки
Когда лучше подходит другая платформа
Платформа с приоритетом локальной работы — не правильный ответ для каждого здания. Для очень крупных установок с сотнями контуров регулирования, строгих требований кибербезопасности уровня энергоснабжающей организации или спецификации, требующей конкретную диспетчерскую систему, может лучше подойти другая архитектура. Loxone сильна там, где важны управление помещениями, локальная автономия, интеграция устройств сторонних производителей и понятная система, эксплуатируемая владельцем. Она слабее там, где проекту нужна очень большая единая база данных, глубокая нативная инженерия BACnet или организация поддержки, работающая только с одной корпоративной платформой. Честный разговор о проекте — о соответствии, а не о верности бренду. Проект может использовать Loxone для управления помещениями и установками, а отдельный диспетчер — для отчётности по портфелю, при условии что граница и ответственность за точки задокументированы. Худший результат — платформа, выбранная из идеологических соображений и затем растянутая за пределы своей роли, потому что полученная система не является ни локальной, ни корпоративного класса. Хорошая спецификация говорит, что делает каждая платформа и чего она намеренно не делает. Границу следует пересматривать при добавлении новой системы, поскольку старые допущения редко выдерживают новый интерфейс. Платформа, которую приходится защищать на каждом совещании, обычно не подходит проекту. Типичные отказы — контроллер, растянутый за пределы ёмкости, шлюз без ответственного, программа с единственным читателем и резервная копия, которая никогда не восстанавливалась. Каждый из них — упущение в проекте, а не дефект продукта.
- Хорошо подходит для помещений, установок и интеграции сторонних устройств
- Менее подходит для очень крупных объектов с единой базой данных
- Разделённые архитектуры работают при документированных границах
- Выбирайте платформу по роли, а не по названию
Элементы системы Loxone и проектные примечания
16 rows| Элемент | Функция | Типичное применение | Проектное примечание |
|---|---|---|---|
| Miniserver | Базовый контроллер и логический движок | Техническое помещение или этажный шкаф | Планировать ёмкость, резервное копирование и замену |
| Extension | Дополнительные входы и выходы | Дополнительные зоны и сигналы установок | Учитывать резерв ёмкости и питание шины |
| Tree | Проводная периферийная шина | Выключатели, датчики и диммеры | Топология, оконцевание и бюджет питания |
| Air | Беспроводная периферия | Модернизация и удалённые датчики | Обследование сигнала и план батарей |
| 1-Wire | Измерение температуры | Датчики пола, труб и помещений | Длина кабеля и адресация |
| Config | Среда программирования | Логика, расписания и сцены | Версионировать и документировать |
| Loxone App | Пользовательский интерфейс | Управление для пользователей и операторов | Представления и права по ролям |
| Интерфейс KNX | Интеграция устройств KNX | Освещение и солнцезащита | Сопоставление групповых адресов |
| Modbus | Интеграция счётчиков и оборудования | Счётчики, инверторы и приводы | Карта регистров и масштабирование |
| Шлюз BACnet | Интеграция устройств BACnet | Техническое оборудование и приточные установки | Сопоставление объектов и нагрузка опроса |
| Шлюз DALI | Управление освещением | Светильники и драйверы | Адресация и группы |
| Питание и резервирование | Электроснабжение и отказоустойчивость | Шкафы и контроллеры | ИБП, защита от перенапряжений и проверка восстановления |
| Сеть | Связь контроллеров и шлюзов | Локальные сети и сети объекта | Сегментация, адресация и источник времени |
| Удалённый доступ | Удалённая поддержка и доступ через приложение | Использование оператором и интегратором | Ролевой доступ, журналирование и отзыв прав |
| Резервная ёмкость | Будущие точки и устройства | Расширение и отделка арендатором | Указывать резерв в процентах |
| Документация и резервные копии | Передача объекта и восстановление | Владелец и служба обслуживания | Версионируется и хранится не на инженерном ноутбуке |
Изображения проекта
3 images
Частые вопросы
01Что такое Loxone Miniserver?
Это базовый контроллер системы Loxone. Он хранит программу, выполняет логику и расписания, предоставляет интерфейсы и координирует модули расширения и периферийные устройства. Управление остаётся локальным, поэтому здание может работать без подключения к облаку. Ёмкость, количество интерфейсов и организацию резервного копирования следует планировать до сборки шкафа.
02Нужно ли Loxone подключение к интернету?
Нет, для локального управления не нужен. Miniserver управляет зданием на объекте. Доступ в интернет используется для удалённого доступа через приложение, уведомлений, обновлений и удалённой поддержки. Проект должен определить, какие функции должны продолжать работать при отказе канала WAN, а пусконаладка должна подтвердить этот перечень, а не предполагать его.
03В чём разница между Tree, Air и 1-Wire?
Tree — проводная шина для выключателей, датчиков и исполнительных механизмов. Air — беспроводная среда для устройств, где прокладка кабеля нецелесообразна. 1-Wire — простая шина, применяемая главным образом для датчиков температуры. Они могут сосуществовать, а выбор зависит от здания, трасс и плана технического обслуживания. Для беспроводных устройств нужны обследование радиосигнала и план замены батарей.
04Может ли Loxone интегрироваться с BACnet?
Да, через шлюз BACnet. Шлюз сопоставляет объекты BACnet с точками Loxone. Прежде чем фиксировать проект, проверьте поддержку объектов, ёмкость по точкам, поведение при опросе и то, что происходит при потере связи со шлюзом. Шлюз без документации — это единая точка отказа, за которую никто не отвечает.
05Подходит ли Loxone для коммерческих зданий?
Может подходить, если локальное управление, открытые интерфейсы и понятная модель поддержки соответствуют проекту. Коммерческим проектам обычно требуется больше документации, ролевого доступа, интеграционного тестирования и планирования жизненного цикла, чем жилому дому. Объём работ и поддержку следует согласовать явно. Коммерческому зданию также нужен назначенный ответственный за программу и резервные копии.
06Как программируется система Loxone?
Логика поведения собирается в Config из функциональных блоков для входов, выходов, логики, расписаний, сцен и тревог. В хороших проектах используют соглашения об именовании, переиспользуемые блоки, контроль версий и проверку точек на объекте до передачи. Программу следует рассматривать как управляемый документ, который другой инженер сможет прочитать и сопровождать.
07Что произойдёт при отказе Miniserver?
Функции этого контроллера прекращают работу до его восстановления или замены. Проект должен ограничивать зону ответственности каждого контроллера, предусматривать резервные копии, запас оборудования и документированную процедуру восстановления. Критичные функции не должны зависеть от единственного недокументированного устройства. Замена должна быть возможна без воссоздания программы по памяти.
Следующий шаг
Приведите нам здание.
Расскажите о типе здания, системах в объёме работ и нужном результате. Мы покажем кратчайший путь к работающей системе.