Urządzenia wejściowe DALI — część III: czujniki ruchu

W tej serii przyglądamy się urządzeniom wejściowym DALI. Część I dotyczyła przycisków, część II czujników światła. Teraz czujniki ruchu — instancja typu 3, opisana w IEC 62386-303.

Czujnik światła wysyła liczbę. Czujnik ruchu wysyła stan zajętości przestrzeni, w której się znajduje. Stan ten dodatkowo zależy od czasu skonfigurowanego w parametrach czujnika. Stąd biorą się wszystkie różnice w jego obsłudze.

Cztery stany czujnika

Instancja typu 3 ma resolution równe 2, co oznacza, że inputValue przyjmuje dokładnie cztery wartości:

Norma opisuje dwa rodzaje urządzeń: czujniki bazujące na ruchu i czujniki bazujące na obecności.

Czujniki bazujące na ruchu (movement based) w momencie wykrycia ruchu przechodzą od razu w stan 0xFF i uznają przestrzeń za zajętą. Same z siebie nie wiedzą jednak, czy ktoś tam nadal jest — zajętość podtrzymuje hold timer, uruchamiany od nowa przy każdej kolejnej detekcji. Dopiero gdy timer wygaśnie, czujnik zgłasza, że przestrzeń jest wolna. Stan 0x55 (wolne, ale wykryto ruch) jest dla nich nieosiągalny, bo ruch z definicji oznacza zajętość.

Czujniki bazujące na obecności (presence) raportują stan przestrzeni wprost, bez wnioskowania. Hold timera nigdy nie uruchamiają — jeśli przestają wykrywać człowieka, od razu zgłaszają stan wolny.

W praktyce najczęściej spotyka się czujniki wykorzystujące technologię PIR (passive infrared, pasywna podczerwień). Element pyroelektryczny reaguje na zmianę ilości promieniowania podczerwonego docierającego do czujnika, a soczewka Fresnela dzieli obserwowaną przestrzeń na strefy. Ciepły obiekt przechodzący z jednej strefy do drugiej daje impuls; człowiek siedzący nieruchomo nie daje żadnego. Dlatego PIR jest zawsze czujnikiem pierwszego rodzaju — bazującym na ruchu.

Czujniki obecności spotyka się rzadko i najczęściej są to czujniki radarowe, które analizują odbicie własnej fali i wychwytują ruchy na tyle drobne, że nieruchomo siedzący człowiek nadal jest widoczny. Nie jest to jednak regułą: to, że czujnik jest radarowy, nie oznacza automatycznie, że w DALI zgłasza się jako czujnik obecności.

Sterownik nie musi tego zgadywać. Bit 3 eventu mówi wprost, z którego rodzaju czujnika pochodzi zgłoszenie, czyli czy urządzenie zastosowało już hold timer.

Rodzaje eventów raportowanych przez czujniki ruchu

Czujnik może wysyłać sześć eventów: movement, no movement, occupied, vacant, still occupied, still vacant. Kodowane są bitowo w jednym evencie — jedna wiadomość niesie jednocześnie informację o ruchu i o zajętości przestrzeni.

Fabryczna konfiguracja eventów, ustawiana w rejestrze eventFilter, wynosi 0000 0011b — włączone są tylko occupied i vacant. Eventy ruchu, braku ruchu i eventy cykliczne (repeat) są domyślnie wyłączone.

Powód jest praktyczny. Czujnik przechodzi między 0xAA i 0xFF za każdym razem, gdy wykryje albo przestanie wykrywać ruch, a przy człowieku poruszającym się po pomieszczeniu dzieje się to bez przerwy. Każde takie przejście to ramka na magistrali. Ogranicza je tDeadtime — minimalny odstęp między eventami — ale fabrycznie wynosi on 100 ms, czyli praktycznie nie ogranicza niczego. Kilka czujników z włączonym eventem ruchu i fabrycznym tDeadtime na jednej linii potrafi wysycić pasmo do tego stopnia, że opóźniają się komendy sterujące oprawami.

Eventu ruchu nie należy więc włączać rutynowo. Jeśli jest potrzebny — a przy logice liczonej w sterowniku jest — trzeba go włączyć świadomie i jednocześnie ograniczyć liczbę ramek timerem tDeadtime, o czym niżej.

Timery

Czas wylicza się jako krok razy mnożnik (0–255), z tolerancją ±5%. Ustawia się je komendami SET HOLD TIMER, SET REPORT TIMER i SET DEADTIME TIMER, odczytuje odpowiadającymi zapytaniami QUERY. tHold dotyczy wyłącznie czujników ruchu — czujnik obecności odpowie na QUERY HOLD TIMER wartością MASK.

Realnie ustawiany czas podtrzymania to 5–15 minut, zależnie od charakteru pomieszczenia.

Dwie zależności warto znać zawczasu: jeśli tReport jest krótszy niż tDeadtime, obowiązuje tDeadtime. A jeśli czujnik wykryje własną awarię, ustawia flagę błędu instancji i przestaje wysyłać jakiekolwiek eventy. Milczenie czujnika nie musi więc oznaczać przerwanego okablowania — warto najpierw odpytać go o status instancji.

Jak realizowana jest obsługa eventów ruchu

Chodzi o to, kto odlicza czas podtrzymania i na jakich eventach opiera się decyzja o zapaleniu i zgaszeniu światła. Są trzy podejścia. Każde da działającą instalację, tylko z inną charakterystyką — a wybór często nie należy do instalatora, bo zależy od tego, co zaimplementował producent sterownika nadrzędnego.

Logika w czujniku. Ustawiasz długi tHold, zostawiasz fabryczny filtr i sterownik słucha tylko dwóch eventów: occupied zapala, vacant gasi. Konfiguracja jest prosta, ruch na magistrali minimalny.

Wadą jest to, że stan systemu przechowuje czujnik. Sterownik nie odlicza niczego — czeka na wiadomość. Jeśli ta wiadomość z jakiegokolwiek powodu nie dotrze, logika się rozjeżdża i nic tego nie prostuje: sterownik nadal uważa, że pomieszczenie jest zajęte, bo nigdy nie dostał informacji przeciwnej.

Logika w sterowniku. Ustawiasz krótki tHold, włączasz eventy movement i no movement, a czas podtrzymania odlicza sterownik. Czujnik przestaje być źródłem decyzji, a staje się źródłem surowej informacji o ruchu.

To podejście jest pewniejsze, bo stan systemu jest w sterowniku — można go sprawdzić, odtworzyć i skorygować. Wymaga za to zapanowania nad ruchem na magistrali — i do tego służy tDeadtime. Sprawdza się ustawienie go na 10 sekund: rozdzielczość czasowa jest w zupełności wystarczająca do sterowania oświetleniem, a eventy nie wysycają transmisji na linii DALI.

Niezależnie od tego, którą z tych dwóch dróg wybierzesz, zostaje jeszcze jedna furtka. Komenda CATCH MOVEMENT wymusza jednorazowe przysłanie eventu ruchu, nawet jeśli ten event jest w filtrze wyłączony — bez zmiany samego filtru. Przydaje się do doraźnego sprawdzenia stanu, na przykład zanim harmonogram wygasi strefę. Jeśli event ruchu jest już włączony, komenda jest ignorowana.

Odpytywanie cykliczne (polling). Trzecie podejście to klasyczny polling: sterownik nie czeka na eventy, tylko sam cyklicznie odpytuje każdy czujnik o jego bieżący stan (inputValue) i na tej podstawie prowadzi logikę.

Działa, ale ma dwie wady wynikające z samej zasady. Szybkość reakcji instalacji zależy wprost od częstotliwości odpytywania — między jednym a drugim zapytaniem sterownik nie wie nic i krótkie wejście do pomieszczenia może w ogóle nie zostać zauważone. A częstotliwości nie da się podnieść dowolnie, bo każde zapytanie i każda odpowiedź to ramki na magistrali, i przy kilkudziesięciu czujnikach na linii rośnie to szybciej niż liczba czujników. W efekcie trzeba wybrać między wolniejszą reakcją a bardziej obciążoną linią.

Trzy przypadki, które nie wyglądają na to, czym są

Kasowanie hold timera działa tylko w jednym ze stanów

Częsta funkcja w budynku biurowym: wychodzę z pomieszczenia, gaszę światło ręcznie przyciskiem i chcę, żeby czujnik zadziałał normalnie dla następnej osoby, która wejdzie za dziesięć sekund. Żeby to miało sens, ręczne wyłączenie musi skasować hold timer — inaczej czujnik przez najbliższe kilkanaście minut uważa pomieszczenie za zajęte.

Do tego służy komenda CANCEL HOLD TIMER. I bardzo często wraca zgłoszenie, że „reset czujnika nie działa".

Jak rozpoznać? Po niepowtarzalności. Ta sama komenda, to samo urządzenie, ten sam scenariusz — raz gasi, raz nie. Zły adres, zła grupa albo źle zaprogramowany przycisk myliłyby się za każdym razem; tutaj wynik zależy od momentu kliknięcia i sprawia wrażenie losowego.

Jak zdiagnozować? Norma mówi, że CANCEL HOLD TIMER kasuje timer i generuje trigger „vacant" — ale tylko wtedy, gdy timer biegnie. Czujnik w stanie 0xFF przy każdej detekcji ruchu uruchamia hold timer od nowa. Komenda trafia więc w timer, który za moment i tak wystartuje ponownie, i cały efekt znika. Przechodzi dopiero w stanie 0xAA — zajęte, ale bez ruchu.

Stąd zależność od geometrii. Przy czujniku o wąskim polu detekcji człowiek stojący przy wyłączniku jest już poza zasięgiem, więc urządzenie zdążyło przejść w 0xAA i reset przechodzi. Przy czujniku obejmującym całe pomieszczenie ten sam człowiek nadal generuje ruch — i to samo kliknięcie nie robi nic.

Jak naprawić? Włączyć w filtrze event no movement (fabrycznie wyłączony) i kolejkować CANCEL HOLD TIMER: nie wysyłać go w chwili naciśnięcia przycisku, tylko trzymać w kolejce do momentu, w którym z czujnika przyjdzie informacja o braku ruchu. Wtedy komenda trafia w timer, który faktycznie odlicza.

To jest w istocie krok w stronę drugiej szkoły. Przy pełnym przeniesieniu logiki do sterownika problem znika całkowicie, bo kasowanie czasu podtrzymania odbywa się w jednostce nadrzędnej, a nie w czujniku.

Optyka czujnika dobrana do innej wysokości montażu

Sam błąd jest tu oczywisty i dość typowy; nieoczywisty jest jego skutek w warstwie DALI. Czujnik przeznaczony do hal wysokiego składowania, zamontowany na niskim stropie, obejmuje pole detekcji znacznie większe, niż zakładał projekt — i odwrotnie, czujnik do niskiego montażu pod halą nie widzi połowy przestrzeni.

Wariant „za szeroko" jest trudniejszy do zauważenia, bo nie objawia się brakiem detekcji, tylko jej nadmiarem. Czujnik praktycznie nie wychodzi ze stanu 0xFF, hold timer jest bez przerwy restartowany, a wszystko, co zależy od stanu „zajęte, bez ruchu" — z resetem hold timera na czele — przestaje działać przewidywalnie.

Czujnik załącza się w nocy, choć nikogo nie ma

Czujnik PIR zamontowany blisko wlotu wentylacji reaguje na ruch powietrza. Przy automatycznym przewietrzaniu w nocy wygląda to na magistrali dokładnie tak samo jak człowiek przechodzący korytarzem.

Jak zdiagnozować? Nagrać ruch na magistrali przez noc i sprawdzić, które czujniki się wzbudzały i o której. Potem zestawić to z monitoringiem, żeby potwierdzić, że w tej przestrzeni faktycznie nikogo nie było, i powiązać adres urządzenia z jego fizyczną lokalizacją. W opisanym przypadku wzbudzenia układały się w rytm automatycznego przewietrzania, a czujnik stał kilka metrów od wlotu wentylacji mechanicznej.

---

Żadnego z tych trzech przypadków nie da się rozstrzygnąć z karty katalogowej ani ze schematu. W każdym trzeba zobaczyć dwie rzeczy: co czujnik ma ustawione w środku i co realnie wysyła na magistralę.

Do tego służy Pilo One. Moduł Monitor nasłuchuje magistralę i pokazuje eventy każdego czujnika w czasie — kiedy zgłasza ruch, kiedy przechodzi w stan wolny, jak często to robi i czy da się to powiązać z tym, co dzieje się w budynku. Nocne wzbudzenia od wentylacji, czujnik z za szerokim polem detekcji, który nie wychodzi ze stanu „ruch", czy zbyt gęste eventy obciążające linię — wszystko to widać wprost na osi czasu, bez podpinania laptopa do szafy.

Konfigurację instancji odczytujesz w aplikacji z każdego urządzenia na linii: filtr eventów, tHold, tReport, tDeadtime. Widzisz je obok siebie, więc od razu wiadomo, który czujnik odstaje od reszty, i możesz je od razu zmienić — bez oprogramowania producenta, bez plików projektu, na obiekcie i z telefonu.

Pilo Agent robi z tego krok dalej: czyta te parametry i sprawdza, czy założona logika sterowania w ogóle ma prawo przy nich działać. Jeśli nie ma — na przykład gdy kasowanie hold timera opiera się na evencie, który jest w filtrze wyłączony, albo gdy przy włączonym evencie ruchu tDeadtime został na fabrycznych 100 ms — mówi, co jest nie tak, proponuje konkretne wartości i po Twojej zgodzie zapisuje je na urządzeniach.

Kolejna część serii: wejścia absolutne — suwaki i pokrętła (IEC 62386-302).