https://www.pexels.com/photo/ideas-whiteboard-person-working-7369/

Sterownik domowy – plany i założenia

Start! Konkurs DSP2017 wystartował, więc nadszedł czas, aby zebrać się w sobie i ruszyć do roboty. Na początek wypada napisać coś o samym projekcie, zatem przedstawię jakie cele chcę osiągnąć, jakie będą podstawowe funkcjonalności oraz jakie narzędzia mam zamiar zastosować i dlaczego.

Nazwa „Sterownik domowy” nie jest zbytnio wyszukana, ale mówi wiele o przeznaczeniu. Będzie to projekt z pogranicza aplikacji webowych oraz IoT, czyli „Internet of Things” (choć to pojęcie może być nadmiarowe w stosunku do tego, co planuję zrobić). Większy nacisk i więcej czasu chcę poświęcić tej pierwszej części. Wynika z powyższego, że projekt będzie miał dwa podstawowe komponenty: hardware i software. Część sprzętowa będzie obejmować centralę opartą na Raspberry Pi (RPI) oraz układy peryferyjne/wykonawcze. Część programowania to oprogramowanie na RPI, aplikacja webowa z bazą danych pod spodem, postawiona gdzieś na zewnętrznym serwerze oraz jeszcze nieokreślony sposób komunikacji RPI – serwer.

Na początek warto opisać cele, jakie chciałbym osiągnąć. Pierwszym z nich i najważniejszym jest cel edukacyjny. Rozpoczęcie blogowania, a dalej start w DSP 2017, a więc realizacja projektu ma za zadanie umożliwić mi poznanie nowych technologii i rozwiązań. Cała otoczka ma dać większą motywację do działania. Jak wspomniałem, głównie chodzi mi o aplikacje webowe, w dalszej kolejności o rozpoznanie platformy Raspberry Pi. To jest główny cel, który ma najwyższy priorytet, tak więc odrzucam wszystkie gotowe rozwiązania. Zdaję sobie sprawę, że to co chcę zrobić już istnieje z dużo większą funkcjonalnością (np. OpenHub czy Domoticz), jednak mi chodzi o naukę, a temat i realizacja tego projektu jest jedynie narzędziem edukacyjnym.

Cel numer dwa to funkcjonalność, którą planuję w przyszłości wdrożyć w swoim mieszkaniu. Projekt realizowany w ramach DSP 2017 na pewno nie będzie na tyle rozwinięty, żeby od razu kłaść instalację w ścianach, jednak może być pierwszym krokiem w tym kierunku.

Z celów przedstawionych w powyższych akapitach wynikają następujące, bardziej szczegółowe funkcjonalności, które chciałbym wdrożyć:

  1. Odczyt danych (stan, wartość) z czujników (czujnik zalania, DHT11, DS1820, PIR, kontaktron)
  2. Sterowanie układem wykonawczym (przekaźnik/triak z optotriakiem)
  3. Przygotowanie GUI z opcją prezentacji danych na rzucie mieszkania oraz możliwością ustawiania stanów wyjść wykonawczych
  4. Możliwość tworzenia i uruchamiania wcześniej przygotowanych programów, np. program „wakacje”, który umożliwi automatyczne zapalanie świateł pod nieobecność domowników
  5. Prosta autoryzacja dezaktywująca czujnik PIR i wyłączająca działający program
  6. Powiadomienie e-mail (a może SMS?) w przypadku przekroczenia wartości krytycznych lub nieautoryzowanego dostępu do mieszkania
  7. Integracja starej kamery internetowej Creative Live! Cam Video IM (VF0540) z czujnikiem PIR + zapis zdjęcia na serwerze

Wytypowałem wstępnie narzędzia/technologie, z których chciałbym skorzystać. W pewnym stopniu daje to ogólne pojęcie o tym, jak całość może wyglądać.

  • Python do skryptów na RPI – z uwagi na rosnącą popularność (globalnie) oraz szerokie wsparcie dla RPI
  • CRON – część skryptów chcę wywoływać cyklicznie, co umożliwi mi właśnie to Unixowe narzędzie
  • Play Framework – dlatego, że reklamują go jako lekki i przyjemny, piszą też, że nowoczesny i ma niski próg wejścia. Miałem wcześniej styczność ze Spring MVC, projekt w Play da mi punkt odniesienia
  • HTML5 – niby zwykły HTML, ale chciałbym wykorzystać bardziej nowości wersji 5, w tym CANVAS do rysowania planu mieszkania
  • CSS – nie sposób pominąć przy aplikacjach webowych, jednak nie czuję mięty do front-endu, dlatego pójdę na łatwiznę stosując Bootstrap
  • JSON – postaram się wykorzystać REST wypluwający właśnie JSON
  • JavaScript ze wsparciem JQuery (a może CoffeeScript?) + AJAX – żeby widoki były przyjemniejsze w obsłudze. Tutaj nowym dla mnie elementem będzie CoffeeScript
  • MySQL – jeden z najpopularniejszych silników bazodanowych w modelu relacyjnym. Początkowo rozważałem MongoDB, ale zdecydowałem się na bazę, którą znam – starczy nowości
  • RabbitMQ – rozważam użycie jako łącznik RPI z aplikacją webową, temat dla mnie nowy, do rozpoznania od zera
  • Heroku – ostatnio atakuje mnie intensywnie reklamami na FB, rozpocznę od analizy czy spełni moje wymagania dotyczące serwera oraz te finansowe

Na koniec wpisu będzie kilka zdań na temat ewentualnych zagrożeń, tzn. wyzwań:]. Pomijając czas i systematyczność, ze spraw technicznych obawiam się czy posiadana przeze mnie, wiekowa już, kamera internetowa będzie chciała współpracować z Raspbianem. Kolejną na tą chwilę niewiadomą jest komunikacja od serwera z aplikacją webową do RPI, gdyż moim dostawcą jest telewizja kablowa, która nie zapewnia stałego adresu IP. Jak dotąd nie mam też pewnego miejsca na serwerze. Jeśli będzie to chmura, to na pewno dojdą obawy o bezpieczeństwo, jakby nie patrzeć, wrażliwych danych. Jeden pomysł mam, choć nie wiem czy to wystarczy.
Jest jeszcze jedna rzecz która trochę mnie martwi – nie mam jeszcze czytelników na blogu. To zadanie na najbliższy wieczór, rozpoznać co mogę z tym zrobić:)

W najbliższych wpisach planuję opisać warstwę sprzętową, być może również proces uruchomienia peryferiów. Prawdopodobnie równolegle będę przerabiał tutorial do Play i tworzył HelloWorld w tym frameworku. Zapraszam do śledzenia kolejnych wpisów dotyczących konkursu Daj się poznać 2017!

3 thoughts to “Sterownik domowy – plany i założenia”

    1. W moim wypadku dopiero robię pierwszą rozkminę :), ale jak widzisz, skupiam się póki co na „hobbystycznych” komponentach. Może kiedyś będę chciał rozwinąć projekt o elementy oparte np. o Z-Wave. Łukasz, nie czytaj tylko, ale również komentuj, podpowiadaj i krytykuj! 😉

Dodaj komentarz

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