Опыт работы DALI2 - Центрсвет и Arlight

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

Всем добрый день. Согласно информации на сайте Wirenboard поддерживает DALI шлюз Ecodim GW2. И это прекрасно. Помогите разобраться с опытом использования.

Что имеем: Wirenboard 7.4, Ecodim GW2, светильники от Центрсвет с DALI2, светодиодные ленты с БП Arlight, поддерживающими DALI2.

Все находится, все настраивается, все хорошо. Но дальше начинаются неприятности со светильниками от Центрсвет.

5 светильников Центрсвет на одной шине, объединены в 2 группы, БП с запасом

9 лент с 9 БП Arlight с поддержкой DALI2

Все блоки питания - все время под напряжением - так норм?

DALI2 управляю исключительно через Яркость - 0 = выкл, выставленное значение = плавно включается. Так норм?

В конфигурации Wirenboard в шаблоне шлюза выключено все кроме параметров присутствия и яркости - эти отпрашиваются раз в 1 сек. Если отключить опрос, то не реагируют на значение яркости.

Если запустить Монитор сети DALI от Ecodim, то видно, что опрос шины DALI идет постоянно и она загруженна на 60-80%.

В чем проблема:

Через какое-то время 2-3-5 светильников Центрсвет пропадают. У них краснеет Присутствие в Wirenboard, их не находит ни WB, ни родная утилита от Ecodim.

Лечится отключением блока питания трека на несколько секунд - после этого все бодры и веселы.
С блоками питания Arlight такого замечено не было.

Понятно, что светильники Центрсвета забиваются постоянными опросами.

Что я делаю не так? Приму любые рекомендации.

3

Добрый день.

Опрос контроллером шлюза - он никак не связан с отпросом шлюза шины. Это совершенно разные интерфейсы, шлюз опрашивает устройства по шине DALI по внутреннему алгоритму и независимо.

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

4

В-общем, поразбирался с этой связкой.

Wirenboard хочет знать детали, но когда нет сообщений, то WB использует pull - регулярный опрос устройств. И в яркости устройств не нашел как конфигурировать - опрашивает каждые 5 сек. Нашёл, что WB не опрашивает Группы - это спасает.

Я не знаю, как так реализовал поддержку DALI2, что забиваются устройства.

Но уважаемые разработчики Wirenboard - НЕ добавляйте пожалуйста регулярный опрос яркости Групп. Или добавьте конфиг параметр для групп и/или устройств - опрашивать или нет.

5

Так, но опрос с контроллера (по modbus) - не сявязан ведь с работой шлюза c шиной Dali. Это совершенно разные, асинхронные процессы, друг от друга не зависящие практически никак.
Контроллер всегда, постоянно, опрашивает Modbus устройства. Это принцип работы протокола.

Тут я не очень понимаю, кто опрашивает? По какой шине?

Устройства - не “забиваются”. Я видет довольно приличные инсталляции с DAKI и общался с интеграторами. Устройства которые перестают отвечать по шине - меняются как бракованые.

В протоколе DALI нет опроса текущих значений групповых параметров.
Вот совсем нет. Контроллер читает значения из регистров.

6

Вот вроде бы ваша информация звучит логично, но техническая поддержка EcoDim говорит обратное: для снижения нагрузки на шину DALI нужно уменьшить частоту опроса устройства…

Лично доказано: уменьшение числа опрашиваемых Modbus регистров снижает нагрузку на шину DALI, которая отображается в интерфейсе.

7

Интересно…
А если ее действительно уменьшить, например, для проверки - просто остановив сам драйвер - то помогает?

8

Убрал опрос большинства каналов, увеличил время опроса для оставшихся, вот что написал клиент, спустя неделю:

Теперь светильники моргают долго. Свечение длиться примерно пол секунды. Раньше они очень быстро моргали.

9

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

10

Вклинюсь в ваш разговор тк так же работаю в связке с экодим и центсвер.

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

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

могу еще накинуть проблему, с которой можете столкнуться — это не все светильники выключаются, остается малозаметное свечение, если смотреть непосредственно на сам светильник. заметили это на Серия / D LINE – как решать эту проблему - хз

1 лайк
11

Тоже вклинюсь в разговор. А может сталкивались с проблемой, когда 2-3-4 светильника из 20 упорно не хотят сканироваться на шине Dali в Ecodim?
При отключении всех светильников с шины и добавлении по очереди по одному — отваливаются другие 3-4 светильника и никак не хотят обнаруживаться.
Все сегменты шины без повреждений, номинал по току БП не не превышен.

Есть подозрение на внутренний конфликт адресов светильников или на закешированные ранее значения. Может есть какой-то soft-reset?

12

У меня была проблема с морганием. И постоянно сыпалась “ошибка шины Dali” в шаблоне WB.
Но как я написал выше, у меня также проблема с добавление на шину некоторых светильников присутствует.

Чтобы избавиться от моргания выключенных светильников:

  1. Пока снял все конфликтные светильники, которые не получается сканировать
  2. Отключил опрос вообще всего, кроме яркости групп

Screen Shot 2024-02-07 в 18.11.36
Screen Shot 2024-02-07 в 18.11.36864×1024 37 KB

13

Тоже добавлю. Была подобная проблема со шлюзом Arlight, их же светильниками в смеси с philips, samsung и ещё чем-то. В 70% случаев - косяки с монтажом или наводки от параллельно идущих кабелей. (отдельный лучи “добра” в сторону арлайта с их кривым софтом и отсутствием свежих мануалов).
И да, опрос всех яркостей 30-40 светильников мог занимать секунд 30-90 без гарантии результата. А в это время всё тормозило. В итоге - опрашивал яркость группы, а индивидуально - забил, ибо недостоверно

ЗЫ: кста, а у тех 2-3-4 светильников адрес джамперами/с “морды” не ставится ли? Бывали и такие чудеса. Или ставить заведомо свободный адрес вручную перед добавлением в шлейф…

14

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

с адресами косяк возникает, когда половина собрана, а половина приедет через месяц и уже просят настраивать) задвоение адресов происходит обычно от 0 и далее по возрастанию. стараюсь первые 10 номеров всегда держать свободными (это проще чем потом пересоздавать сеть)

1 лайк
15

Вообще есть ощущение (или самовнушение) что шлюз лучше работает через TCP. Сейчас на объекте опрашиваю 63 светильника и 16 групп одновременно, пока работает без задержек. на вспышки не проверяли.

16

главное, при TCP не использовать одновременно утилиту экодим и опрос с WB, а то там можно посидеть за первые секунды)

17

Было такое на другом объекте со шлюзом KNX-DALI после прописывания адресов. Помогла перезагрузка светильников по питанию)

18

А какой период опроса у яркости групп? TCP или RTU?

19

Слышал еще историю, даже кажется про Арлайт, что надо попробовать с выключателя быстро включить/выключить светильники 10 раз и у них должен произойти софт-сброс.
Написал об этом своему дилеру Центрсвет, они уточнили у технического отдела и сказали что стоит это попробовать, возможно поможет.
Пока руки не дошли.

По поводу TCP — у меня очень долго опрос Ecodim проходил и регулярно ошибки опроса светильников выпадали.
Потом я взял USB-RS485 переходник, подключился через него к RTU порту и тогда сканирование сети и связь с Ecodim гораздо лучше пошла. Прям “летает” по сравнение с TCP.

лавное, при TCP не использовать одновременно утилиту экодим и опрос с WB

Я никогда не мог подключиться к Ecodim, пока не выключу порт RS-485 в Wirenboard на котором висит екодим.

20

Всё в дефолтных значениях “В порядке очереди”

21

Немного странно, ТСP вроде как надежней и меньше подвержен проблемам, может с сетью что-то было не так…

двойное подключение к шине, это когда контроллер wb по ТСР и утилита экодим по ТСР