Infinity: system automatyki domowej - współpraca z czujnikiem tlenku węgla

Każdorazowe jego naciśnięcie powoduje określone zachowania modułu. Naturalne staje się, by każde naciśnięcie przycisku zmieniało stan włączenia na przeciwny (przykładowo jak wentylator był włączony, to należy go wyłączyć). Ta koncepcja doskonale się sprawdza w przypadku ręcznego sterowania, jednak nie zdaje egzaminu we współpracy z typowym, dostępnym w handlu, czujnikiem tlenku węgla (fotografia 1).

Fot.1 Czujnik tlenku węgla

Moduł oczekuje „naciśnięcia i puszczenia” przycisku (z czasem trwania stanu zwarcia około pół sekundy), natomiast czujnik, pracując w roli przycisku, „naciśnie” i trzyma tak długo, aż poziom tlenku węgla nie spadnie poniżej dopuszczalnego progu. By uzyskać potrzebną funkcjonalność, niezbędne jest dodatkowe wsparcie w postaci modułu i temu jest poświęcony bieżący artykuł. Jest to adaptacja używanego już elementu do nowej roli (sterownika do zarządzania oświetleniem). Z punktu widzenia sprzętowego moduł był opisany dwa miesiące temu, toteż chcąc sobie odświeżyć informacje, należy sięgnąć do tego numeru czasopisma.

Element sterujący wentylatorem był szczegółowo opisany w poprzednim miesiącu (moduł o identyfikatorze PWC001). Jego instalację w systemie pokazuje rysunek 1. Przekaźnik elektromagnetyczny zawarty w module pozwala włączać napięcie sieciowe 230V dla silnika wentylatora. Do ręcznego sterowania zastosowany jest przycisk przystosowany do montażu na szynie DIN pokazany na fotografii 2. Każdorazowe naciśnięcie przycisku, jako elementu lokalnego wpływającego na pracę modułu sterującego wentylatorem (PWC001), zmienia stan na przeciwny. Jest to „ręczny” tryb pracy. Każda zmiana stanu generuje na magistralę RS485 informację o aktualnym statusie.

Rys.1 Instalacja elementu sterującego wentylatorem

Z punktu widzenia komunikacji moduł PWC001 jest elementem typu SLAVE, który wymaga aktywnego dostępu do magistrali RS485 (przykładowo wysyła na magistralę informację o zmianach stanu). Ze względu na półdupleksowy tryb jej pracy, do tej magistrali musi zostać przyłączony element typu MASTER (zarządzający komunikacją). Tę funkcję spełnia procesor komunikacyjny.

Idea działania typu MASTER – SLAVE była już szczegółowo przedstawiona w poprzednich odcinkach cyklu. By całość, w sensie komunikacyjnym, sprawnie działała, moduł MASTER (procesor komunikacyjny) musi „znać” listę przyłączonych modułów. Wysyłając cyklicznie zezwolenia na aktywny dostęp do magistrali RS485 do „znanych” modułów (polecenie REPLY), powstaje możliwość przesyłania komunikatów pomiędzy dowolnymi modułami. Każdy komunikat wysłany na magistralą komunikacyjną jest odbierany przez każdy moduł do niej przyłączony.

Fot.2 Przycisk przystosowany do montażu na szynie DIN

Fot.3 Czytnik stanów - brak wlutowanego optotriaka

Dodatkowy element, jako adaptacja sprzętowego rozwiązania do zarządzania oświetleniem, jest czytnikiem stanów i monitoruje stan zwarcia styków przekaźnika znajdującego się w czujniku tlenku węgla. Ponieważ w nowej, dodatkowej roli nie realizuje on funkcji włączania, nie ma wlutowanego optotriaka (fotografia 3). Taka lekko okrojona sprzętowo funkcjonalność w połączeniu z odpowiednim oprogramowaniem tworzy nowy element systemu.

Styki przekaźnika znajdującego się w czujniku tlenku węgla są przyłączone do modułu jako zewnętrzny przycisk. W zależności od wykrytej zmiany stanu, na magistralę RS485 są wysyłane odpowiednie informacje, które ze względu na charakter pracy typu SLAVE muszą być synchronizowane przez procesor komunikacyjny. To z kolei implikuje konieczność, by jego identyfikator (COSEN1) był „znany” procesorowi (w części poświęconej procesorowi komunikacyjnemu wszystkie te identyfikatory zostały zdefiniowane i zapisane w pamięci konfiguracyjnej modułu zarządzającego komunikacją).

Do podstawowych funkcji nowego modułu (czytnika stanów) należy wygenerowanie odpowiedniego polecenia dla sterownika zarządzającego pracą wentylatora. Dodatkowym jego „zmartwieniem” jest informowanie serwera www o aktualnym stanie czujnika wykrywającego tlenek węgla. Te informacje adresowane do serwera www mają wpływ na treść generowanej strony dla przeglądarki internetowej.

Podczas monitorowania stanu styków przekaźnika w czujniku czadu, wykrywany jest moment zwarcia styków, co odpowiada sytuacji, gdzie czujnik wykrył przekroczenie dopuszczalnego stężenia tego gazu oraz moment rozwarcia styków odpowiadający sytuacji, gdy stężenie niebezpiecznego gazu spadło poniżej krytycznego poziomu. Ta funkcjonalność ma swoje odbicie w strukturze danych konfiguracyjnych zapisanych w pamięci nieulotnej.

Podobnie jak we wszystkich innych modułach, po zmontowaniu układu przed pierwszym uruchomieniem należy zdjąć zworkę P301 odłączającą stabilizator napięcia od reszty układu. Po jego zasileniu (nominalne napięcie zasilające wynosi 12V) trzeba zmierzyć napięcie generowane przez stabilizator impulsowy. Wartość napięcia powinna wynosić około 5V, co oznacza, że stabilizator pracuje poprawnie i można założyć zworkę P301. Kolejnym krokiem przy uruchamianiu modułu jest właściwe ustawienie FUSE. Ich modyfikację wykonuje się, przyłączając programator do układu. W sytuacji, gdy programator „zobaczy” procesor modułu, możliwe stanie się zaprogramowanie jego ustawień oraz zaprogramowanie jego pamięci FLASH. 

ATmega88 - zaprogramowanie ustawień i zaprogramowanie pamięci FLASH

• CKDIV8 – bit konfiguracyjny nakazujący dzielić częstotliwość sygnału zegarowego przez 8, należy tę opcję wyłączyć (fabrycznie nowy mikrokontroler ma tę opcję włączoną),
• wybrać wariant sygnału zegarowego (SUT_CKSEL) jako zewnętrzny rezonator kwarcowy z częstotliwością w przedziale 3...8 MHz,
• przydatne jest zaznaczenie opcji EESAVE (kasowanie pamięci FLASH niezbędne przy każdym zaprogramowaniu mikrokontrolera nie będzie jednocześnie powiązane z kasowaniem pamięci EEPROM, w której są przechowywane dane konfiguracyjne).

Oczekiwany zestaw konfiguracji FUSE pokazuje rysunek 2 (AVR STUDIO 4).

Rys.2 Oczekiwany zestaw konfiguracji FUSE (AVR STUDIO 4)

Pierwsze uruchomienie po załadowaniu programu do wewnętrznej pamięci FLASH mikrokontrolera spowoduje zapis do pamięci konfiguracyjnej EEPROM domyślnych ustawień. Blok danych konfiguracyjnych przechowywany w pamięci nieulotnej jest opatrzony 16-bitową sumą kontrolną CRC, która pozwala na wykrycie pierwszego uruchomienia modułu i zapisania w pamięci konfiguracyjnej domyślnych wartości parametrów. Znajdują się tam różne informacje, jak pokazano poniżej, a struktura bloku konfiguracyjnego jest pokazana na listingu 1, który jest dostępny w Elportalu wśród materiałów dodatkowych do tego numeru.

Dane konfiguracyjne przechowywane w pamięci nieulotnej mikrokontrolera

• MyDeviceID – własny identyfikator sterownika jako ciąg składający się maksymalnie z 8 znaków, domyślnie jest KEY1,
• Password – hasło wymagane przy aktywnej konfiguracji parametrów sterownika składające się maksymalnie z 6 znaków, domyślnie jest MAGIC,
• EventDestinDeviceID [ EventDestin-DeviceArraySize ] – zbiór identyfikatorów innych modułów/urządzeń, do których należy wysłać polecenie włączenia/wyłączenia, jest to tablica mieszcząca 4 identyfikatory, z których każdy składa się z maksymalnie 8 znaków, domyślnie tablica jest pusta,
• StatusDestinDeviceID [ StatusDestinDeviceArraySize ] – zbiór identyfikatorów innych modułów/urządzeń, do których należy wysłać informacje statusowe (informacje o przekroczeniu dopuszczalnego stężenia gazu), jest to tablica mieszcząca 2 identyfikatory, z których każdy składa się z maksymalnie 8 znaków, domyślnie tablica jest pusta,
• KeyStartService – polecenie, jakie należy wysłać do modułów, których identyfikatory są wymienione w tablicy EventDestinDeviceID (polecenie włącz/wyłącz) w reakcji na wykrycie zwarcia styków przekaźnika w czujniku tlenku węgla (wykrycie przekroczenia dopuszczalnego stężenia gazu), domyślnie jest polecenie CHON (włącz),
• KeyStopService – polecenie, jakie należy wysłać do modułów, których identyfikatory są wymienione w tablicy EventDestinDeviceID (polecenie włącz/wyłącz) w reakcji na wykrycie rozwarcia styków przekaźnika w czujniku tlenku węgla, domyślnie jest polecenie CHOFF (wyłącz),

Każdorazowe uruchomienie modułu, po zaprogramowaniu niezbędnych obwodów (kanał komunikacji szeregowej, zegar, porty), zawsze związane jest z odczytem danych konfiguracyjnych zawartych w pamięci EEPROM. Te dane mają istotne znaczenie dla działania modułu. Własny identyfikator (MyDeviceID) wpływa na rozpoznawanie poleceń odbieranych poprzez kanał transmisji szeregowej z magistrali RS485. Jak we wszystkich już opisanych modułach, odebrane polecenia są przetwarzane pod warunkiem zgodności identyfikatora odebranego z magistrali komunikacyjnej z własnym zapisanym w pamięci konfiguracyjnej. Moduł również reaguje na „uniwersalne imię” GENERAL.

Algorytm obsługi transmisji szeregowej oraz analizy treści odebranych poleceń jest identyczny jak w opisanych ostatnio sterownikach. W stosunku do modułu zarządzającego oświetleniem, w tym przypadku oprogramowanie w sposób istotny różni się przede wszystkim w obsłudze przycisku (stanu przekaźnika w czujniku wykrywającym tlenek węgla). Monitorowanie stanu zwarcia odbywa się w przerwaniach od upływającego czasu i jest zrealizowane w konwencji automatu synchronicznego.

Rozwiązanie pokazuje listing 2 (dostępny w Elportalu), gdzie w zależności od stanu automatu w poprzednim cyklu oraz aktualnego zwarcia styków przekaźnika widzianego jako wartość logiczna odczytywana na odpowiednim wyprowadzeniu portu generowana jest informacja do bufora klawiaturowego (mieszczącego jeden znak). W tej obsłudze uwzględnione jest zjawisko dzwonienia styków występującego w chwili ich zwarcia i rozwarcia. W momencie załączenia przekaźnika przez czujnik gazu, do bufora klawiatury jest wpisywany kod znaku określający początek stanu aktywnego (wykrycia niebezpiecznego stężenia gazu).

Analogicznie, wyłączenie przekaźnika odpowiada wpisaniu do bufora znaku określającego koniec stanu aktywnego. Stan bufora klawiatury jest badany w pętli głównej programu, gdzie ewentualnie następuje programowa reakcja na zaistniałe zdarzenia. Pokazuje to listing 3 (dostępny w Elportalu), gdzie w zależności od początku lub końca stanu aktywnego sensora gazu rozsyłane jest polecenie sterujące (wywołanie funkcji SendKeyEvents) oraz wysyłany jest do serwera www aktualny status (wywołanie funkcji SendStatusEvents).

Wysłanie polecenia włącz/wyłącz (pokazuje to listing 4 dostępny w Elportalu) sprowadza się do wygenerowania odpowiedniego polecenia w formacie, jaki obowiązuje w komunikacji w obrębie całego INFINITY. Możliwe jest wygenerowanie ich do kilku adresatów (do tylu, ile jest wpisanych w pamięci konfiguracyjnej). Pozwala to włączyć wentylator, którego zadaniem jest usunięcie niebezpiecznego gazu oraz włączyć jakąś sygnalizację (przykładowo czerwone światełko czy jakiś sygnalizator akustyczny). W moim przypadku wystarczy sam wentylator, gdyż czujnik gazu sam z siebie daje znać o sobie i nie jest konieczna dodatkowa sygnalizacja. W rzeczywistości algorytm pokazany na listingu 4 jedynie generuje dane do odpowiedniego bufora, które będą czekały na zezwolenie na transmisję (odebranie odpowiedniego polecenia od procesora komunikacyjnego).

Równolegle z akcją wysłania poleceń włączających/wyłączających zrealizowana jest operacja poinformowania serwera www o zaistniałej sytuacji (w ogólnym przypadku dowolnego urządzenia, gdyż rozwiązanie jest na tyle elastyczne, że umożliwia utworzenie dowolnego wariantu). Rozwiązanie pokazuje listing 5 (dostępny w Elportalu).

Moduł czytnika stanów rozpoznaje polecenia przedstawione w tabeli 1 (tabele też znajdują się w Elportalu, w materiałach dodatkowych do tego artykułu).

Konfigurację i sprawdzenie działania w warunkach laboratoryjnych najprościej jest wykonać, bazując na znanym już zestawie diagnostycznym (fotografia 4). Jest to bardzo pomocny element we wszelkich działaniach konfiguracyjnych i naprawczych. Tu warto zauważyć, że po każdym poleceniu wysłanym do modułu występuje w parze polecenie REPLY, które jest wyrażeniem zgody na aktywny dostęp do magistrali komunikacyjnej. Ilustruje to tabela 2.

Fot.4 Zestaw diagnostyczny

Zgodnie z informacjami z tabeli 2 współdziałające elementy zrealizują następujące działania, co jest symbolicznie pokazane na rysunku 3. Załóżmy wstępnie, że czujnik czadu wykrył niebezpieczne stężenie gazu, co skutkuje włączeniem jego przekaźnika elektromagnetycznego. Jego stan jest ciągle monitorowany przez czytnik stanów i w reakcji na powyższe zdarzenie moduł ma przygotowane do wysłania odpowiednie dane, musi jedynie zaczekać na odpowiedni moment. Procesor komunikacyjny, działający we własnym rytmie, wysyła do modułu COSEN1 zezwolenie na dostęp do magistrali komunikacyjnej (krok 1, rysunek 3).

Rys.3 Działania realizowane przez poszczególne elementy

W odpowiedzi moduł ten wysyła polecenie włączenia zasilania dla wentylatora (krok 2, rysunek 3) oraz wysyła do serwera www aktualny status związany z wykryciem niebezpiecznej sytuacji (krok 3, rysunek 3). W wyniku tych działań serwer www będzie „znał” aktualny stan oraz moduł sterujący wentylatorem zrealizuje polecenie przychodzące z magistrali komunikacyjnej (włączy zasilanie dla wentylatora) oraz przygotuje do wysłania informacje o własnej zmianie stanu.

Dane te nie zostaną wysłane natychmiast i będą oczekiwały na właściwy moment, który nadejdzie po jakimś czasie. Procesor komunikacyjny zezwoli modułowi PWC001 na dostęp do magistrali komunikacyjnej (krok 4, rysunek 3) i w reakcji moduł ten poinformuje serwer www o zmianie stanu włączenia zasilania (krok 5, rysunek 3). Wyłączenie wentylatora odbędzie się na identycznej zasadzie. Uzyskanie „bezpiecznej atmosfery” spowoduje rozłączenie styków a to w konsekwencji będzie elementem wyzwalającym kolejny ciąg zdarzeń, który doprowadzi do oczekiwanego stanu.

Fot.5 Czujnik wykrywający ruch

Na zakończenie można zaproponować interesujące rozwiązanie. Nie jest ono zrealizowane w moim systemie, ale umożliwia uzyskanie atrakcyjnej funkcjonalności. Wyobraźmy sobie, że zamiast czujnika tlenku węgla zostanie zastosowany czujnik pasywnej podczerwieni (typowy czujnik wykrywający ruch pokazany na fotografii 5), co stwarza możliwość włączenia oświetlenie na określony czas w wyniku wykrycia ruchu.

W tym celu trzeba dodać kolejny moduł (jednocześnie nadając mu unikalny identyfikator, który również należy dodać do listy identyfikatorów zapisanych w procesorze komunikacyjnym) i wskazać jako adresata poleceń moduł zarządzania oświetleniem (polecenie ADDSUP) z określeniem, że na wystąpienie początku stanu aktywnego zostanie wysłane polecenie włączenia z czasem trwania przykładowo 3 minuty bez reakcji na wystąpienie końca stanu aktywnego (polecenie dla odpowiedniego wariantu ma być puste).

W kolejnej części zostanie opisany moduł pomiaru temperatury.