Urządzenia wejściowe DALI — część II: czujniki światła

W tej serii przyglądamy się urządzeniom wejściowym DALI. O oprawach i zasilaczach DALI napisano już wszystko, o czujnikach i panelach przycisków — niewiele, choć to one najczęściej decydują, czy instalacja zachowuje się sensownie. Część I dotyczyła przycisków. Teraz czujniki światła.

Co właściwie wysyła czujnik światła

W porównaniu z przyciskiem czujnik światła jest prosty. IEC 62386-304 przewiduje dla niego jeden jedyny event: informację o poziomie oświetlenia. Filtr eventów ma tylko jeden używany bit — można nim ten event włączyć albo wyłączyć, i na tym kończą się możliwości.

Cała rzecz rozgrywa się w tym, co siedzi w takim evencie. Czujnik nie wysyła na magistralę „420 lx" — wysyła liczbę ze swojej własnej skali. Norma stawia to zresztą jasno: odczyt jest wartością względną i luksów nie reprezentuje.

Dlaczego 200 to nie zawsze 200

Zacznijmy od rzeczy, która bywa myląca. Event z czujnika światła zawsze niesie 10 bitów — więcej nie zmieści się w 24-bitowej ramce. Norma to ujednolica: przy rozdzielczości do 10 bitów odczyt jest przeskalowywany do postaci dziesięciobitowej, przy wyższej na magistralę idzie 10 najstarszych bitów.

Wniosek jest wygodny: liczba w evencie zawsze mieści się w przedziale 0–1023 i zawsze oznacza procent zakresu czujnika. Jeśli czujnik zgłasza 512, widzi mniej więcej połowę swojego zakresu — nieważne, czy w środku pracuje na 10, 14 czy 16 bitach. Norma osiąga to, wyrównując odczyt do najstarszego bitu i wypełniając resztę powtórzonym wzorcem, właśnie po to, żeby sterownik mógł liczyć zawsze tak samo.

Skoro tak, to skąd biorą się rozjazdy między czujnikami? Z zakresu pomiarowego. Ten norma pozostawia producentowi i różnice bywają ogromne — jeden czujnik mierzy do 2 000 lx, drugi do 30 000, trzeci do 100 000.

Trzy czujniki patrzące na to samo biurko oświetlone na 500 lx:

Wszystkie trzy działają poprawnie, wszystkie widzą to samo światło, a odczyty różnią się pięćdziesięciokrotnie. Nic tu nie jest zepsute — po prostu każdy z nich zgłasza procent czegoś innego.

Rachunek działa też w drugą stronę i wtedy staje się użyteczny. Czujnik o zakresie do 100 000 lx wysyła 100: sto ze 1023 to niecałe 10% zakresu, czyli mniej więcej 10 000 lx na powierzchni czujnika. Bez znajomości zakresu ta sama setka nie znaczy zupełnie nic.

Rozdzielczość nie zmienia więc znaczenia liczby, tylko jej dokładność — na ilu krokach czujnik dzieli swój zakres. Ma za to znaczenie wewnątrz urządzenia: domyślna minimalna szerokość pasma histerezy jest podana osobno dla każdej rozdzielczości i wychodzi mniej więcej na procent pełnej skali.

Warto przy tym rozróżnić dwie drogi dojścia do odczytu, bo dają różną dokładność. Event, który czujnik sam wysyła na magistralę, jest zawsze przycięty do tych dziesięciu bitów. Ale kiedy sterownik odpyta czujnik wprost — komendą QUERY INPUT VALUE, a kolejne bajty przez QUERY INPUT VALUE LATCH — dostanie pełną wartość w rozdzielczości urządzenia, nawet kilkubajtową. Do regulacji światła dziennego dziesięć bitów spokojnie wystarcza, więc w praktyce pracuje się na eventach.

Co sterownik robi z tą liczbą dalej

Tu dochodzi warstwa, o której norma nie mówi nic, bo to już nie jej działka — a która potrafi wywrócić całe powyższe rozumowanie.

Sterownik nadrzędny może z tą dziesięciobitową liczbą zrobić coś po swojemu. Popularne podejście to rozciągnięcie jej z powrotem do rozdzielczości zadeklarowanej przez czujnik: przychodzi 512, sterownik sprawdza, że urządzenie pracuje na 16 bitach, i zapisuje u siebie ~32 000. Przy czujniku dziesięciobitowym te same 512 zostaje 512.

Efekt jest taki, że dwa czujniki o identycznym zakresie, patrzące na to samo światło i wysyłające na magistralę dokładnie tę samą liczbę, wyglądają w sterowniku zupełnie inaczej — bo różnią się rozdzielczością. Norma zrobiła wszystko, żeby odczyt był od rozdzielczości niezależny, a warstwa wyżej tę niezależność cofa.

Zdarza się to nawet między egzemplarzami tego samego modelu. Bywały partie produkcyjne, w których po aktualizacji firmware'u czujnikom wzrosła rozdzielczość. Kupujesz dwa identyczne czujniki, ten sam symbol katalogowy, ta sama karta — a jeden deklaruje 10 bitów, drugi 14, i sterownik rozciąga ich odczyty na dwie różne skale.

Zakres znajdziesz w karcie katalogowej i to jest ta liczba, której naprawdę potrzebujesz. Warto tylko sprawdzić, czego dotyczy: Tridonic dla czujnika DALI MSensor G3 PIR 5DPI podaje 0,5–2 000 lx na główce czujnika, co na oświetlanej powierzchni odpowiada mniej więcej 3–6 300 lx. Czujnik mierzy to, co do niego dociera, a nie to, co widać na biurku.

Kiedy czujnik wysyła event

Event leci z dwóch niezależnych powodów:

1. odczyt wyszedł poza pasmo histerezy — powyżej hysteresisBandHigh albo poniżej hysteresisBandLow,
2. minął czas tReport od poprzedniego eventu, niezależnie od tego, co czujnik widzi.

Szerokość pasma to max(hysteresis% × inputValue, hysteresisMin). Pasmo jest asymetryczne — rozpina się w górę albo w dół, zależnie od kierunku ostatniej zmiany — i po każdym evencie liczy się je od nowa.

Ta asymetria ma konkretną konsekwencję. Gdy sygnał rośnie, górna granica pasma siedzi dokładnie na ostatnim odczycie, więc każdy kolejny wzrost wyzwala event — w tym kierunku pasmo nie chroni w ogóle. Dopiero zmiana kierunku daje zapas: żeby po wzroście wyzwolić event spadkiem, odczyt musi cofnąć się o pełną szerokość pasma. I odwrotnie.

Ustawia się je komendami SET REPORT TIMER (0x30), SET HYSTERESIS (0x31), SET DEADTIME TIMER (0x32) i SET HYSTERESIS MIN (0x33), odczytuje przez QUERY (0x3C–0x3F). Wpisanie zera do hysteresis wyłącza wyzwalanie zmianą i zostają same eventy cykliczne. Zero w tReport wyłącza event cykliczny.

Dwie szkoły regulacji

Tę decyzję trzeba podjąć świadomie, bo obie drogi dają działającą instalację, tylko o zupełnie innym charakterze.

Pierwsza: tylko eventy cykliczne. Wyłączasz wyzwalanie histerezą i opierasz regulację wyłącznie na tReport. Tempo ustawiasz wprost tym timerem — może być szybkie, jeśli skrócisz okres — ale w praktyce stosuje się 20–40 sekund. Działa pewnie i przewidywalnie.

I w większości obiektów właśnie o to chodzi. Regulacja światła dziennego nie musi nadążać za każdą chmurą — nikt nie czuje się dobrze, mając nad głową dyskotekę. Wolniejsze i mniej dokładne nadążanie za słońcem jest dla użytkownika komfortowe, a dla magistrali przewidywalne.

Druga: histereza. Czujnik reaguje na rzeczywiste zmiany, więc regulacja lepiej podąża za światłem dziennym i trzyma poziom dokładniej. Za to wymaga dobrze napisanej pętli regulacji w sterowniku nadrzędnym. Czujnik mierzy przecież światło opraw, które sam reguluje, więc każda korekta zmienia to, co czujnik widzi — przy nieprzemyślanej implementacji układ zaczyna oscylować.

Przy tej drugiej drodze tDeadtime przestaje być parametrem drugorzędnym. To on trzyma wyzwalanie histerezą w ryzach: dopóki nie upłynie, instancja nie wyśle kolejnego eventu. Bez niego seria szybkich zmian odczytu zamienia się w serię ramek. I jeszcze jedna zależność, o którą łatwo się potknąć: jeśli ustawisz tReport krótszy niż tDeadtime, i tak obowiązuje tDeadtime.

Na co uważać

Jedno pomieszczenie reguluje się, drugie stoi na 100%

Ktoś konfiguruje strefy w budynku, kopiuje ustawienia i zakłada, że skoro wszystkie czujniki mają dążyć do tej samej wartości, to wszędzie wyjdzie tak samo. Wystarczy jednak, że czujniki różnią się zakresem pomiarowym albo — przy sterowniku rozciągającym odczyt — rozdzielczością, i nie wyjdzie.

Objaw jest wtedy taki, że jedna strefa steruje się jako tako, a druga siedzi na 100% albo od razu na poziomie minimalnym. Nic przy tym nie oscyluje — regulacja dojeżdża do ogranicznika i tam zostaje, bo od startu widzi „o wiele za jasno" albo „o wiele za ciemno". Łatwo wziąć to za uszkodzony czujnik: oprawa świeci pełną mocą i nie reaguje na nic.

Jak diagnozować? Porównać surowe odczyty z magistrali o podobnej porze dnia, przy podobnym oświetleniu. Jeśli jeden czujnik pokazuje 10, a drugi 200, to znaczy, że pierwszy widzi 1% swojego zakresu, a drugi 20% swojego — i trzeba sprawdzić w kartach katalogowych, czy te zakresy są w ogóle takie same. Zwykle nie są. Jeśli natomiast na magistrali obie liczby są zbliżone, a mimo to strefy zachowują się inaczej, to znaczy, że rozjazd powstaje dopiero w sterowniku — wtedy warto porównać deklarowane rozdzielczości obu urządzeń (QUERY RESOLUTION).

Jak naprawić? Wyznaczyć wartość docelową osobno dla każdego czujnika, na podstawie tego, co on sam pokazuje w docelowych warunkach.

Producenci systemów podchodzą do tego dokładnie tak samo. Inventronics w przewodniku do DALI Professional 3 wymaga, żeby czujniki pracujące w jednej regulacji były tego samego typu, podobnie zamontowane i dawały zbliżoną wartość kalibracji — na ich własnym przykładzie dwa czujniki w jednej strefie dają 1,4% i 5,9%. zencontrol każe ustawiać wartość docelową skalibrowanym luksomierzem, czyli fizycznym pomiarem przy każdym czujniku. Żaden nie zakłada, że liczba przeniesiona z jednego czujnika zachowa sens na drugim.

Przypadkowy refleks wybija regulację

Czujniki światła wychodzą z pudełka z włączoną histerezą. Oprócz eventów cyklicznych wysyłają więc eventy asynchronicznie, w dowolnym momencie, gdy zmiana przekroczy pasmo.

Przy czułym czujniku i wąskim paśmie wystarczy krótki refleks, żeby odczyt wyskoczył poza pasmo. Światło odbite od czegoś lustrzanego — szyby, blatu, tarczy zegarka na czyjejś ręce — przejedzie po czujniku przez sekundę i to już wystarczy, żeby go punktowo prześwietlić. Czujnik zgłasza zmianę, sterownik reaguje, a jasność w strefie skacze bez żadnego związku z tym, ile naprawdę jest światła dziennego.

Im węższe pasmo i czulszy czujnik, tym więcej takich przypadkowych eventów. Przy kilku czujnikach na linii robi się z tego wyraźnie większa dynamika: zbędny ruch na magistrali i zmiany jasności, które użytkownik widzi, a których nic nie tłumaczy.

Histereza działa tu odwrotnie, niż podpowiada nazwa. To nie jest filtr wygładzający — to wyzwalacz. Węższe pasmo oznacza więcej eventów, nie mniej.

Jak rozpoznać? W ruchu na magistrali widać nieregularne eventy pojedynczych czujników, wypadające z rytmu eventu cyklicznego, a jasność w strefie zmienia się skokowo bez uchwytnej przyczyny na zewnątrz.

Jak naprawić? Poszerzyć pasmo (hysteresis i hysteresisMin), wydłużyć tReport i ustawić tDeadtime tak, żeby ucinał serie. Jeśli aplikacja nie potrzebuje szybkiej regulacji, najprościej przejść na pierwszą szkołę i zostać przy samych eventach cyklicznych.

---

Obie sytuacje mają wspólny mianownik: liczba z czujnika światła nic nie znaczy bez wiedzy o urządzeniu, które ją wysłało, a konfiguracji czujników nie da się kopiować między strefami tak swobodnie jak grup czy scen.

Jedno i drugie widać wprost na magistrali. Moduł Monitor w Pilo One pokazuje, ile ruchu generuje każdy czujnik i czy jego eventy trzymają się rytmu timera, czy wypadają z niego nieregularnie — czyli czy ustawienia histerezy nie robią z linii ruchliwego miejsca bez powodu. Pilo Agent czyta z kolei parametry konfiguracji instancji i sprawdza, czy przy takich wartościach histerezy, tReport i tDeadtime regulacja ma prawo działać stabilnie. Jeśli nie ma, proponuje konkretne ustawienia i po Twojej zgodzie sam je zapisuje na urządzeniach.

Kolejna część serii: czujniki ruchu (IEC 62386-303).