Sterownik domowy – co nowego

Tak jak zapowiadałem, wracam do mojego projektu Sterownika domowego rozpoczętego już prawie rok temu, w ramach konkursu „Daj się poznać 2017”. Słowem przypomnienia, ma to być system będący namiastką inteligentnego domu, w którym znajdują się różnego rodzaju sensory i układy wykonawcze sterujące pracą np. oświetlenia. Za czasów mojej ostatniej aktywności na blogu, przed około pół roku oraz już po zakończeniu inicjatywy DSP2017, w wolnych chwilach (choć nie było tego dużo) starałem się poświęcić czas na pociągnięcie tematu do przodu. W tym i w kolejnych wpisach, chciałbym przybliżyć nowe elementy jakie pojawiły się w moim amatorskim systemie. Pierwsza część dotyczyć będzie widoków aplikacji webowej, czyli fragmentu systemu z interfejsem użytkownika, który agreguje i prezentuje wszystkie informacje dostępne w systemie. W kolejnych odcinkach opiszę krótko jakie backendowe mechanizmy zastosowałem i co chcę jeszcze wdrożyć. Myślę, że nie zabraknie również wzmianki na temat sprzętowej części projektu.

Taki opis powinienem zacząć od podstaw, w tym wypadku będzie to nowy widok, do którego wydzieliłem opcję konfiguracji typów czujników. Na razie nie wszystkie parametry są edytowalne, cześć z nich nawet nie powinna być zmieniana, bo jest nierozłączna ze ich sprzętową naturą (np. czy jest to czujnik pomiarowy czy wyjście sterujące). Do tej pory wprowadziłem możliwość zmiany mniej istotnych parametrów – koloru oraz ikony, które będą reprezentowały dany typ czujnika. W planach jest wprowadzenie możliwości zmiany częstotliwości odczytu stanu czujników.

Konfiguracja typów sensorów
Konfiguracja typów sensorów

Pod spodem opcji zmiany koloru i ikony siedzi JavaScript komunikujący się z serwerem za pomocą AJAXa. Wybór ikony wykonywany jest w dodatkowym oknie przeglądarki, spośród zdefiniowanych wcześniej pozycji. Jako komponent wyboru koloru skorzystałem z biblioteki Spectrum. Te dwie właściwości są wykorzystywane w kilku miejscach aplikacji do identyfikowania typu, przykładowo w widoku tablicy informacyjnej, agregującej informacje o wszystkich sensorach.

Tablica informacyjna
Tablica informacyjna

Powyższy widok to dashboard, który ma zawierać kluczowe informacje o komponentach systemu. W tym miejscu znajdowała się będzie m.in. informacja o stanie sensora/odczytanej wartości oraz możliwe będzie szybkie przejście do jego szczegółów bądź wyświetlenie logów z nim związanych. Wybór elementu, jaki ma się znaleźć w tym miejscu, możliwy jest w formularzu tworzenia/edycji sensora.

Widok ze szczegółami sensora
Widok ze szczegółami sensora

W klasie Sensor pojawiło się kilka nowych właściwości, m. in. reprezentujących informację czy sensor należy do grupy czujników środowiskowych czy bezpieczeństwa. Pierwsza z nich będzie agregowała komponenty pomiarowe parametrów środowiskowych (po 1 na pomieszczenie), druga natomiast komponenty pełniące funkcje zapożyczone z systemów alarmowych (przykładowo kontaktrony). W przyszłości planuję wykorzystać tego typu informacje do wyświetlenia na jakimś oddzielnym dashboardzie, w jakiejś ciekawej formie wizualnej.

Kolejną nowością w strukturze aplikacji jest zmiana powiązania sensora z pomieszczeniem jego instalacji. W tej chwili zależność ta jest ustawiana automatycznie. Funkcjonalność edycji pomieszczenia doczekała się interfejsu umożliwiającego wybór obszaru danego wnętrza.

Wybór obszaru pomieszczenia
Wybór obszaru pomieszczenia

Administrator systemu ma możliwość odrysowania za pomocą kolejnych odcinków figury odwzorowującej obszar pomieszczenia. Informacja ta zapisywana jest w encji pomieszczenia (Room) i wykorzystywana dalej w momencie wyboru lokalizacji sensora. Ustalenie miejsca instalacji czujnika będzie skutkowało sprawdzeniem, do jakiego pomieszczenia należy taki element przypisać. Jako algorytm weryfikujący czy punkt znajduje się w określonym obszarze zastosowałem PNPOLY – Point Inclusion in Polygon Test (W. Randolph Franklin), bo przecież nie ma sensu odkrywać koła na nowo, a ten problem niekoniecznie jest aż tak trywialny jakby się mogło początkowo wydawać.

Szczegóły pomieszczenia
Szczegóły pomieszczenia

Jak widać, kolejne wierzchołki zaznaczonej figury zapisywane są w nawiasach oddzielonych średnikiem. Tu na razie nie mam innego pomysłu, jak ciekawie można takie dane wyświetlić w kompaktowej formie. Na screenie powyżej znajduje się przykład listowania czujników przypisanych do pomieszczenia, z podziałem na czujniki aktywne oraz archiwalne. To kolejna drobna zmiana jaką wprowadziłem. Nie ma opcji kasowania czujników, bo są one mniej lub bardziej powiązane z innymi encjami, choćby z logami. Nie chcę pozbywać się informacji z systemu, jednie oznaczyć je jako nieaktualne. Z identycznego rozwiązania skorzystałem w widoku szczegółów sterownika.

Z dalszych zmian, uzupełniłem boczny pasek ze szczegółami zaznaczonego sensora w widoku planu mieszkania. Jest to w zasadzie coś na wzór dashboardu, tylko w nieco innej wizualnie formie, niestety obecnie mało nadającej się do wyświetlania na urządzeniach mobilnych.

Plan mieszkania z informacjami o sensorach
Plan mieszkania z informacjami o sensorach

Wspominałem kilkukrotnie o logowaniu informacji związanych z sensorami. Taki dziennik zdarzeń to ‚must have’ dla admina systemu. U mnie będzie możliwość przeglądania logów z poziomu aplikacji. Po co? A tak dla ćwiczenia i praktyki:) Do widoku wrzuciłem prosty filtr sortujący dane dla danego sensora, po wybranym przedziale dat oraz poziomie logowania. W ramach poznawania nowych modułów, dorzuciłem też opcję eksportu do PDF (A PDF module for Play Framework 2), na razie w bardzo prostej formie.

Dziennik zdarzeń
Dziennik zdarzeń

Z grubsza to by był komplet zmian jakie udało mi się przygotować. No, nie jest tego dużo, ale czasu również mało. Z wniosków jakie pojawiły się w trakcie kolejnych prób najważniejszy może okazać się ten, dotyczący konieczności re-konfiguracji lub optymalizacji zainstalowanego softu na malince. Pierwsze testy pokazały, że 1 GB RAM może okazać się niewystarczający do tego, co chcę zrobić. Dla przypomnienia, na jednym RPI chciałem uruchomić aplikację webową (Play Framework), bazę PostgreSQL i serwer RabbitMQ. Sytuacja wygląda tak, że odpalenie tych trzech elementów powoduje solidne zużycie pamięci. Na pewno mógłbym zainwestować w kolejny RPI, np. wersję RPI Zero W i tam przenieść choć jedną z tych aplikacji. Być może wyłączenie środowiska graficznego w Raspbianie i sprawdzenie co tam chodzi ‚out of the box’ byłoby również pomocne. W skrajnym przypadku mógłbym sprawdzić rynek pod kątem dostępności innych komputerów jedno-płytkowych z większą pamięcią, na których można byłoby postawić linuxo-pochodny system. Rozwiązania jakieś tam są, ale jeszcze do weryfikacji, na tą chwilę nie mam wystarczającej wiedzy, żeby podejmować jakieś kroki zaradcze.

To by było już chyba wszystko co chciałem napisać. Bardzo wierzę w to, że w najbliższym czasie będę częściej coś publikował. Poczyniłem pewne zobowiązanie, opłacając hosting i domenę na kolejny rok. Kasa wydana, więc teraz nie może się zmarnować:) W związku z tym serdecznie zapraszam do śledzenia mojej aktywności i dzielenie się komentarzami w sprawie projektu i nie tylko;) Pozdrawiam.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *