В статье описан некоторый опыт и впечатления от знакомства с INTELLIGENT Контроллер DALI-LOGIC-LITE-PS-x1 (230B, Ethernet)
Контроллер выполнен в пластмассовом корпусе, с возможностью крепления на дин-рейку.
Питание контроллера от сети, имеет встроенный блок питания, который, так же, является блоком питания шины DALI.
То есть, устанавливать в цепь шины дополнительный блок питания нет необходимости. Этоявляет спорным преимуществом перед контроллерами требующими внешнего питания шины DALI, так как встречаются устройства, например, датчики, так же со встроенным питанием и два таких устройства на шине могут привести к непредсказуемым последствиям.
Шокирует стоимость контроллера - более 81 тысячи рублей, хотя в нутри ни чего такого нет, даже нет аккумулятора или захудалой батарейки, для автономной работы при отключении электричества. Блок питания, вышедний у нас из строя, был приобретен на замену в интернет-магазине за тысячу рублей, так же в интернете заказали остальные детали(два транзистора и источник опорного напряжения) вышедшие из строя. Весь ремонт обошелся в 1150 рублей вместе с доставкой в пункт выдачи.
Удобство контроллера заключается в том, что он имеет возможность подключения из любого места в локальной сети и даже извне, нет необходимости быть рядом с ним. Так как не имеет встроенного web-интерфейса, как это встречается в роутерах и управляемых LAN-комутаторах, то подключение выполняется из установленной на компьютер или мобильное устройство программы.
С программой для мобильного устройства я не знаком, так как работы по настройке проводил удаленно. Программа была установлена на ПК, к которому производилось удаленное подключение. Большим минусом является отсутствие в программе индикации состояния устройств. Состояние устройств(в моём случае блоков питания) пришлось определять посредством нажатия кнопки "Считать всё" в окне устройства выбранного из списка, по положению ползунка диммера.
Если говорить о самой программе, то она свои функции выполняет, но очень "сырая" и неудобная. Подробного описания программы нет, по этому, готовьесь познавать её посредством проб и ошибок.
При каждом новом сканировании устройства занимают новое положение в списке, адреса могут несовпадать с нумерацией предыдущго сканирования, а так же "вставать" по несколько устройств на один адрес. В окне каждого устройства есть поля названия устройства и примечания к нему, которое вы можете заполнить на своё усмотрение, но при изменении адреса устройства описание не перемещается с ним, а остается на том месте в списке устройств, где оно было ранее.
Что бы избежать подобных неприятностей следует произвести расстановку устройств на адресах в удобном вам порядке в разделе "Адресация", во вкладке "Ручная адресация исполнительных устройств", путем перетаскивания с клетки на клетку, после каждого перемещения нажимая кнопку "Считать статусы". Тут тоже есть недоработки. В программе есть подсказка, что если адрес занят несколькими устройствами, то он отмечен серым цветом. Это не всегда так. У нас случилось, что адреса с несколькими устройствами отображались как адреса с одним устройством. Понять на каком адресе несколько устройств можно в списке исполнительных устройств, выбирая устройство и нажимая в его окне "Считать всё". Если поля заполняются нормально, то на адресе одно устройство, если поля не изменяются(остаются пустыми), то на адресе несколько устройств.
После манипуляций с изменением адресов сохраните конфигурацияю через меню "Файл". Помните, что "бекапы"(сохраненные копии) - наше всё.
Прописывая имена устройств в списке исполнительных устройств, по окончании работы с устройством, обязательно нажимайте кнопку "Считать всё" и "Выгрузить всё", проделывайте это для каждого устройства. По окончании или перед перерывом в работе с программой сохраняйте конфигурацию, создавая очередность файлов, что бы в случае ошибки можно было вернуться к предыдущему состоянию.
Однако, стоит учитывать, что перемещенные по списку устройства или внесенные правки в названия или описания действительны только для текущей конфигурации и не будут восстановлены при загрузке предыдущей. Из-за этого может возникнуть путаница. Придётся проверять исполнительные устройства включением выключением.
Перейдем к обзору программирования контроллера.
С сайтов продавцов можно скачать документацию в формате PDF, с некоторыми пояснениями программ, программных байтов и функций применяемых при программировании сценариев.
Не знаю как случится у вас, а у меня сразу возникло множество вопросов. Хотя в документации даны примеры, но всё на столько поверхностно, что проще самому познавать процесс методом проб и ошибок.
Спросите "А чего же не обратиться в службу поддержки?", отвечу, обращался и полученный ответ не порадовал:"Если мы будем объяснять - как, что и куда, то чем будут заниматься наши инженеры?..." - то есть, вы оплатили не хилый ценник за контроллер, ещё и услуги программирования оплатить...
Простите, отвлёкся - эмоции...
Для программирования необходимо знать назначение имеющихся "Триггеров", но их описания нет. Есть "Универсальный" триггер, триггер "Таймер/Время" и триггер "Событий".
Не буду утверждать с уверенностью в 100%, но по моему, сугубо личному, мнению(так как контроллер был в руках не длительное время) триггеры имеют следующие назначения:
Триггер событий - для работы с данными получаемыми от каких либо датчиков. Например, датчиков движения/объема, температуры или освещенности.
Триггер времени - для работы с повременными событиями, ориентирован на время получаемое с сервера времени.
Универсальный триггер - способен обрабатывать некоторые переменные времени, арифметические и логические функции, и функции задержек.
Далее идут сценарии или сцены(как кому удобнее), которые сначала необходимо написать в текстовом документе, а только за тем продгрузить в контроллер. П.О. контроллера реагирует только на явные ошибки в написании самих функций и выдает сообщение об ошибке в строке с нумерацией.
Но это только в случае написания функций, об ошибках в последовательности функций, что код сценария работать не будет, он вам не сообщит.
Если бы производитель озаботился и создал эмулятор, то наличие контроллера не требовалось бы, а весь процесс занимал бы меньше времени и ознакомление было бы полее приятным, менее мучительным, но увы...
Если Вы, уважаемый читатель, хоть немного знакомы с каким-то языкаом программирования, то может возникнуть вопрос о наличии знаков решетки в коде сценариев, потому, как программисты приучены к тому, что решетка - есть комментирование. Тут не так. Решеткой обозначается метка на которую ориентируется исполняемый код.
Меня интересовало программирование временных интервалов, для срабатывания устройств на включение и выключение, по этой причине буду рассматривать вариант изменения 2 примера в 3 пункте документа "Описание скриптового языка для создания смарт-сцен и логических функций".
Каждый час осветительные приборы должны снижать яркость с 254 на установленное значение = 160, на 20 секунд.
Дано:
@newday
LV5=9
#start
GetTime LV1, LV2, LV3, LV4
if(LV1==LV5) jump #minutes
jump #start
#minutes
if(LV2==00) jump #seconds
jump #start
#seconds
if(LV3==0) jump #milliseconds
jump #start
#milliseconds
if(LV4==0) jump #work
jump #start
#work
dali.arc L(0), All, 254
wait 20s
dali.arcL(0), All, 160
if(LV5>=20) jump #newday
LV5=LV5+1
wait 1000
jump #start
Разберем содержимое.
GetTime - функция получения времени. Время может быть получено с ПК, с которого ведется настройка или сервера времени, при условии, что сервер и порт указаны в настройках. Если сервер не локальный, то сеть или сегмент сети с контроллером должен иметь выход в Интернет.
LV1, LV2, LV3, LV4 - локальные переменные времени: часы, минуты, секунды и милисекунды.
LV5 - локальная переменная в которую вынесено значение времени срабатывания.
Метки по которым выполняются переходы:
#newday, #start, #minutes, #seconds, #milliseconds, #work
#newday - начинаем новый день
#start - вроде каретки, для перепрочтения команд
#work - метка исполняемого фрагмента с параметрами для исполнительных устройств, в данном примере - это блоки питания.
Как это работает:
1. Контроллер смотрит наличие определенного триггера, сравниваем время прописанное в сценарии, начинается новый день. Пока время нового дня не достигло указанного значения, то есть 9 часов, то контроллер прокручивает код, но не начинает выполнять его.
2. Как только пробило 9 часов, срабатывает метка #work и начинается её выполнение: контроллер устанавливает все устройства(All) первой шины(L0) в максимальное значение яркости 254.
3. Ожидание 20 секунд и яркость снижается до значения 160.
4. Контроллер видит значение LV5>=20, но это время ещё не наступило.
5. Выполняется условие прибавляющее час: LV5=LV5+1
Предварительный итог: Начиная с 9 утра приборы каждый новый час будут менять яркость на 20 секунд, пока не выполниться условие LV5>=20, пока не наступит 20 часов.
Как только LV5>=20, устройства получают команду на максимальную яркость и встречают новый день, что бы начать цикл снова в 9 часов.
Задача перед нами состояла в том, что бы все устройствана на шине одновременно начинали и прекращали работать(светиться и гаснуть) несколько раз в сутки, в установленное заказчиком время.
Времени для сдачи проекта оставалось мало, а, как сказано выше, другого контроллера на руках нет, то перепробовав кучу вариантов, остановился на таком.
@newday
LV5=6
#start
GetTime LV1, LV2, LV3, LV4
if(LV1==LV5) jump #minutes
jump #start
#minutes
if(LV2==00) jump #seconds
jump #start
#seconds
if(LV3==0) jump #milliseconds
jump #start
#milliseconds
if(LV4==0) jump #work
jump #start
#work
dali.arc L(0), All, 254
wait 7200s
dali.arcL(0), All, 0
wait 43200s
dali.arcL(0), All, 254
wait 10800s
dali.arcL(0), All, 0
if(LV5>=0) jump #newday
wait 1000
jump #start
Начинаем день в 6 утра и запускаем полное свечение.
Светим 2 часа(7200s)
выключаем на 12 часов, до 8 вечера(43200s)
включаем на 3 часа(10800s)
Как только истекает время последнего таймера ожидания, гасим свет,
ждём 0 часов(полночь) и переходим в новый день, что бы в 6 утра начать заново.
На этом всё. Если представится возможность, если этот контроллер ещё раз попадет в руки, то дополню статью.