Логика взаимодействия и работы устройств DALI

Периферийные устройства
1

Хочу разобраться в тонкостях реализации распределения управления устройствами DALI подключаемыми к контроллеру WB через шлюз WB-DALI3. Для этого опишу свое представление по уровням от низшего к высшему. Поправьте меня если что то не правильно опишу.
В системе управления освещением построенной на протоколе DALI с использованием оборудования WB я вижу три уровня управления/взаимодействия устройств.

1. Уровень 1 - использующий возможности самого протокола и шины DALI (широковещательное, групповое и индивидуальное управление). На нем устройства на шине имеют свои адреса и “слушают эфир” на шине как только слышат команду в свой или общий адрес выполняют команду которая транслируется по шине для этого адреса. Адреса и команды задаются при настройке конкретной шины, в которой выключатели DALI (либо классическим выключателям с СК и адаптерами DALI к которым они подключены) “привязываются” к своим светильникам. На этом уровне мы можем включать-выключать, димировать, менять световую температуру светильников объединенных в группы и привязанных к тем или иным выключателям DALI.

2. Уровень 2 - связка проложенных шин DALI и модуля WB-DALI3. Модуль имеет возможность подключить три шины DALI самостоятельно работающих на “Уровне 1”, производить настройку этих шин (создание групп, сцен, назначение адресов светильникам и функций выключателям). Может ли модуль WB-DALI3 осуществлять связку/передачу команд из шины 1 в шину 2 например, без использования контроллера WB8? Или он может только наблюдать за эфиром в шинах и передавать эту информацию от шин на контроллер и обратно. То есть если по другому задать вопрос: добавляет ли модуль WB-DALI3 сам по себе (без контроллера WB8) нового функционала в базовую работу шин DALI?

3. Уровень 3 - Шины DALI + модуль WB-DALI3 + контроллер WB8. Тут уже мы получаем возможности сценарного управления устройствами на шинах DALI подключенных к модулю WB-DALI3 в зависимости от любых событий происходящих в системе. Управление происходит путем отправки команд на адреса устройствам находящимся на шинах подключенных к модулю WB-DALI3 по сценариям заложенным в контроллер WB8.

Тут возникает вопрос, как при этом решаются конфликты с настроенной работой устройств на Уровне 1? Например выключатель с адресом 34 настроен на включение и димирование светильников с адресами 12 и 27 объединенных в группу 3. Он высылает в шину DALI команду согласно настройкам на Уровне 1, но при этом через шлюз эту же команду видит и контроллер и тоже пытается отправить свои команды управления согласно настроенным сценариям в эту же шину. Будет ли конфликт в этом случае, особенно если команды не совпадают или совпадают частично. Так же хотелось бы понять возможны ли конфликты выполнения команд на Уровне 2 если настройки действий там отличаются от Уровня 1.

3

Николай, доброго дня! Нужно изучить документацию по вашему запросу. Вернусь сегодня, как буду полностью в теме :slight_smile:

4

Хорошо структурированный вопрос. Сначала одно уточнение.

Автономно управлять светильниками могут только выключатели со встроенной логикой, которые работают как самостоятельные управляющие устройства (мастера) на шине. Стандартные кнопки и датчики DALI-2 Part 301–304 сами команд светильникам не шлют, они только рассылают события, которые должен обрабатывать управляющий контроллер. В системе с WB-DALI3 таким контроллером выступает связка шлюза и контроллера Wiren Board.

Нет, не добавляет. Шлюз реализует только низкоуровневый приём и передачу DALI-кадров и обменивается ими с контроллером через Modbus-регистры, а весь DALI-стек (сканирование шин, адреса, группы, сцены, обработка нажатий) реализован сервисом wb-mqtt-dali на контроллере. Поэтому без контроллера шлюз не может ни пересылать команды из шины 1 в шину 2, ни настраивать шины, ни отрабатывать нажатия кнопок, в том числе на собственных входах. Верна ваша вторая формулировка, о том что шлюз наблюдает за эфиром в шинах, передаёт информацию на контроллер и команды контроллера обратно в шины.

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

Таких конфликтов быть не может, потому что у шлюза нет собственных «настроек действий». Он сам ничего не решает и не отправляет, все команды в шину формирует контроллер. Уровень 2 в вашей модели это прозрачный транспорт между шинами и контроллером, а не отдельный источник команд.

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

Удалось мне ответить на ваши вопросы?

5

В проекте планирую использовать модуль DIU-L-4N-C от INBRIGHT для подключения обычных звонковых (кнопочных) выключателей на шину DALI. Так же на шине будут светильники и драйверы DALI которыми собственно и будем управлять.
Задача от заказчика организовать на низком уровне (Уровень 1) управление вкл/выкл (и желательно димирование) для групп светильников привязанных к своим выключателям. Для обеспечения резервирования в случае возможного отказа контроллера.
Собственно этот вопрос был связан с желанием понять как может и может ли резевироваться система на шине DALI при ее проектном управлении контроллером WB.
То есть в случае отсутствия контроллера или связи с ним, шина DALI работает в автономном режиме по тем алгоритмом которые запрограммированы в устройствах подключенных к ней.
А когда контроллер на связи, то уже он осуществляет управление.
А второй вопрос стоял в том стоит ли использовать на выключателях модули DIU-L-4N-C, которые могут как раз обеспечить возможность автономной работы шины в случае отключения контроллера. Насколько быстро будут проходить от них команды в контроллер по протоколу DALI и выполняться запрограммированные действия. Или не заморачиваться с резервированием и заводить все выключатели на входы модулей WB и оставлять только логику работы через контроллер.

6

Да, выбранный подход задачу решает, это ровно тот случай выключателей со встроенной логикой, о котором я писал выше, судя по описанию на сайте INBRIGHT. То есть модуль работает как самостоятельное управляющее устройство, привязки «кнопка, группа» хранятся в нём и настраиваются инструментами производителя (NFC-программатор NFCU-1), а не из интерфейса Wiren Board. Поэтому при недоступности контроллера WB8 ожидаем управление от кнопок. Включение и выключение делается короткими нажатиями, диммирование обычно удержанием, точный перечень поддерживаемых модулем команд уточните у INBRIGHT.

На что обратить внимание.

  1. Согласуйте номера групп. Группы светильникам вы назначаете с контроллера через WB-DALI3, и те же номера групп должны быть прописаны в настройках DIU. Тогда локальное управление и сценарии контроллера будут работать с одними группами, а контроллер увидит команды модуля в мониторе шины и выровняет отображаемое состояние периодическим опросом.
  2. Питание шины. Ваша схема закрывает отказ контроллера WB8, потому что шина питается не от него, а от встроенного источника шлюза (230 В). Но сам WB-DALI3 остаётся точкой отказа, при пропадании его питания шина обесточится и локальное управление тоже перестанет работать. Если требование к резервированию жёсткое, запитайте шину от внешнего DALI-блока питания, а встроенный источник этой шины отключите в настройках шлюза.
  3. Совместную работу WB-DALI3 именно с модулями INBRIGHT мы не тестировали. Стандарт DALI допускает несколько управляющих устройств на одной шине, но поведение конкретного модуля лучше подтвердить у производителя и проверить связку на стенде до монтажа.

Если остались вопросы, с удовольствием отвечу.

7

Спасибо большое за информацию. Пока все понятно. Как получу шлюз, будем тестировать.

8

Простите, только сейчас увидел, что вы дополнили сообщение, отвечу на добавленные вопросы по порядку.

Первая часть верна, вторая требует уточнения. В DALI нет механизма главный и резервный, локальные привязки в DIU работают всегда, а не только при пропадании контроллера. Оба источника управления равноправны и работают параллельно, светильники выполняют команды в порядке поступления, итог определяет последняя. Поэтому при проектировании сценариев учитывайте, что локальное управление активно и при живом контроллере. Например, сценарий погасил группу, а человек кнопкой тут же включил её обратно, как с обычными звонковыми выключателями и реле MR6C v2. Простите за занудство, но должен был уточнить для понимания :nerd_face:

Здесь три разных пути, у них разная задержка.

  1. Нажатие - светильники через привязки DIU. Команда уходит из модуля сразу в шину, контроллер не участвует. Реакция на уровне десятков миллисекунд, глазу незаметна. Это самый быстрый путь, и он же работает при отказе контроллера.
  2. Нажатие DIU - контроллер, чтобы на кнопку реагировали ещё и сценарии. Быстрого штатного канала здесь может не оказаться. Монитор шины это инструмент отладки, автоматическая реакция сценариев на чужие команды в шине в документации не описана. Штатно контроллер узнаёт об изменениях через периодический опрос состояния светильников, то есть с задержкой до периода опроса, и триггером будет новое состояние светильника, а не само нажатие. Если же DIU умеет работать ещё и как адресуемое DALI-2 input-устройство и рассылать события нажатий, контроллер сможет получать их сразу, поддержка кнопок и датчиков DALI-2 в шлюзе заявлена. Есть ли такой режим у DIU-L-4N-C, уточните у INBRIGHT, и связку стоит проверить на стенде.
  3. Кнопки на входах модулей WB. Нажатия доставляются на контроллер событиями Быстрого Modbus сразу по факту нажатия, дальше правило отправляет команду в шину через шлюз. Суммарная реакция «нажатие → свет» обычно незаметна глазу, точное значение зависит от загрузки шин и проверяется на стенде.

Решение определяется ценой отказа света для заказчика.

  1. Если свет в помещениях обязан работать при отказе контроллера или связи с ним, локальный уровень на DIU оправдан. Плата за это в том, что конфигурация ведётся в двух местах (группы через веб-интерфейс WB, привязки в DIU через NFC), плюс возможные пересечения локальной логики со сценариями и описанные выше ограничения по реакции сценариев на нажатия.
  2. Если допустимо, что при отказе контроллера светом временно нельзя управлять, схема когда все кнопки на входы модулей WB и вся логика в правилах контроллера проще и предсказуемее. Одна точка настройки, любые сценарии, включая работу между шинами, быстрая доставка нажатий.
  3. Рабочий компромисс: критичные зоны (коридоры, лестницы, основной свет) на DIU с локальными привязками, остальные выключатели на входы WB.
  4. Ну и не стоит забывать про дизайнера (или как в моём случае - супружницу :grinning_face_with_smiling_eyes:) - они обычно очень капризные в выборе разной электроустановки на помещение/квартиру.

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

Если мы закрыли все ваши вопросы - отметьте это сообщение как решение, если нет - спрашивайте.