Uoo-light cz.1: Plan działania

Uoo-light cz.1: Plan działania

Hurra – sukces – mój blog nie skonał po pierwszym wpisie :). To dobrze wróży całemu projektowi. Jak pisałem w poprzednim wpisie, pierwsza wersja mojego zdalnego sterowania światłem nie doczekała się realizacji. Wiele przyczyn miało na to wpływ i postaram się w miarę możliwości je wyeliminować. Przede wszystkim warto podzielić sobie pracę na etapy (sprinty?), zeby ogrom różnych tematów i zadań nie zwalił się na głowę. Jeśli sprinty to zgodnie ze zwinnymi technikami (Working software is the primary measure of progress) warto byłoby mieć szybko coś działającego choćby w bardzo okrojonym zakresie… Ale tutaj projekt nie jest stricte programistyczny – dlatego kluczowa jest szybka konstrukcja urządzenia prototypowego. Kolejna sprawa to pamiętać, że jak jest coś do wszystkiego to jest do niczego. Jak to ma się do projektu? W poprzednim podejściu nie lubiłem podejmować decyzji – urządzenie miało być do bólu uniwersalne – najlepiej, żeby płytka umożliwiała wlutowanie zarówno przekaźników jak i triaka z optotriakiem (i w zależności od potrzeby od 1 do 3) i mnóstwa innych rzeczy, oprogramowanie też miało być super-hiper uniwersalne. Obecnie planuję jak najszybciej podejmować decyzje – a najwyżej potem w miarę możliwości robić je coraz bardziej uniwersalne.

Założenia

Chciałbym, żeby urządzenie było maksymalnie autonomiczne. Brak dostępu do „chmury” (czyli mojego serwera), brak dostępu do internetu czy nawet brak jakiejkolwiek sieci wifi nie powinno przeszkadzać w podstawowych funkcjach urządzenia (przy braku WiFi urządzenie może być samo Access Pointem). Praca w sieci domowej czy w chmurze powinna być opcjonalna (ale możliwa – w późniejszych etapach projektu). urządzenie ma być też jak najprostsze dla użytkownika końcowego (też w późniejszych etapach – na początku ma działać ;-)). Wszystkie opcje zaawansowane powinny być ukryte a urządzenie proste w obsłudze i nie wymagające od użytkownika wiedzy ponad to co konieczne. Wyszukiwanie urządzenia  ma być maksymalnie proste (nie każdy przecież uważa, że najprostszą metodą odnalezienia urządzenia w sieci jest użycie Wiresharka, skanera portów czy grzebanie w logach DHCP).

Plan działania

Słowo wstępne

Plan postanowiłem podzielić na 3 oddzielne części: hardware (projekt i wykonanie sprzętu), firmware (w tym GUI webowe) i software (czyli wszelkiego rodzaju aplikacje klienckie i serwerowe – wszystko co nie jest uruchamiane bezpośrednio na naszym urządzeniu). Z tego wszystkiego najbardziej kluczowe i niezbędne jest firmware. Dlaczego? Dlatego, że hardware początkowo (a nawet nie początkowo tylko na cały okres projektowania) może zastąpić prototyp poskładany na pająka a aplikacja kliencka również nie będzie niezbędna do działania pod warunkiem przejrzystego interfejsu www zawartego w firmwarze samego urządzenia. Oczywiście wszystko może jeszcze ulec zmianie, ale warto mieć plan – choćby po to, żeby mieć co zmieniać.

Hardware

  • Zbudowanie prototypu – zasilanie dowolne, element sterujący dowolny, byle od strony oprogramowania był tożsamy z płytką docelową
  • Rozpoczęcie projektowania płytki/płytek – jako narzędzie wybrałem Eagle, bo znam to oprogramowanie (z poprzednich podejść i innych projektów), a dla płytki o rozmiarach mieszczących się w puszce montażowej, jest całkowicie darmowe (darmowe jest dla płytek do 2 warstw ścieżek i wymiarów do 80cm x 100cm).
  • Stworzenie biblioteki z elementami, które nie występują w bibliotekach standardowych Eagle’a.
  • Stworzenie płytki zasilania i sterowania – obecnie plan zakłada dwie płytki złożone „na kanapkę” – jedna z zasilaczem (najprawdopodobniej Hi-Link HLK-PM01, który świetnie opisano na tej stronie) i elementami sterującymi (triak/optotriak, ewentualnie jakiś przekaźnik)
  • Stworzenie płytki z modułem WiFi – tu jeszcze sporo do zadecydowania oprócz tego, że będzie tam moduł WiFi (stabilizator napięcia z kondensatorami, oraz pare rezystorów i kondensatorów) to jeszcze trzeba przemyśleć sprawę tego w jaki sposób będzie wyglądać interfejs dla użytkownika – jeden guzik czy dwa, może joystick, albo impulsator. Do tego dodatkowe gadżety – fotorezystor, LED-y informujące o stanie – a wszystko dopasowane do obudowy, którą też trzeba zaprojektować.
  • Obudowa – tu też jeszcze sporo do zdecydowania – mam kilka pomysłów – niestety pozostaje najtrudniejsze – zadecydować 🙂

Firmware

  • Proof of concept – pierwszym krokiem będzie stworzenie programu, który będzie umożliwiać włączenie i wyłączenie GPIO – najlepiej przez prosty interfejs www.
  • Zdalna aktualizacja – warto szybko przewidzieć możliwość zdalnej aktualizacji, żeby nie trzeba było mieć urządzenia przypiętego cały czas do komputera.
  • Podstawowa konfiguracja sieciowa urządzenia – zahardkodowane dane sieci wifi nie są dobrym pomysłem – możliwość konfiguracji sieci oraz możliwość jej prostego (choć nie zbyt prostego) zresetowania jest potrzebna.
  • Ładny interfejs www – tak jak „je się oczami” tak i w naszym projekcie ładny wygląd i szybkie działanie, choć nie są konieczne, to mogą przesądzić o sukcesie projektu. Na pewno będzie to AJAX – nie dość, że rozwiązanie to jest szybkie w działaniu to jeszcze odciąży nam urządzenie. Skłaniam się do Angular JS wraz z interfejsem Material – ale jeśli będzie zbyt ciężki w obsłudze (przy pierwszych próbach pojawiły się różne niespodzianki), to może spróbuję czegoś prostszego – np. Bootstrap.
  • Możliwość wyszukania w sieci – Jak już pisałem Wireshark czy nmap nie mogą być rozwiązaniem docelowym. Technologii jest wiele – Apple preferuje Bonjour, Windows – SSDP, Android nie wiem co (ale się dowiem). Można również przemyśleć coś własnego – nasłuchiwanie na adresie multicast/broadcast albo samodzielne wysyłanie na taki adres pakietu co kilka (naście?) sekund.
  • Możliwość sterowania jakimś prostym protokołem  – nie jest fajnie za każdym razem, gdy chcemy zgasić/zapalić światło, logowanie się na interfejs www danego włącznika i dopiero tam kliknięcie na guzik. Niezbędna będzie możliwość centralnego sterowania wszystkimi włącznikami. Na razie wymyśliłem takie warianty (docelowo zaimplementuję kilka z nich, choć nie wszystkie):
    • Centralne sterowanie wszystkimi włącznikami z aplikacji mobilnej która komunikuje się z poszczególnymi modułami – to rozwiązanie jest obowiązkowe ze względu na to, że mój zegarek nie ma przeglądarki – a chciałbym móc w ten sposób sobie zgasić światło (no i przy okazji nauczyć się programować mój własny zegarek).
    • Centralne sterowanie z aplikacji webowej w chmurze – moduły rejestrują się na naszym serwerze, który komunikuje się z nimi i przekazuje im to co  my chcemy zrobić. Zaletą jest możliwość zgaszenia żonie światła w łazience nawet z innego kontynentu. Wadą jest to, że jak nie ma internetu a żona zgasi mi światło w łazience (za pomocą włącznika) – to sobie ze smartfona go nie włączę :(.
    • Dedykowana centrala – jakieś urządzenie (może jakieś ambitniejsze typu Raspberry Pi, C.H.I.P., czy choćby przerobiony access point. Wadą jest koszt dodatkowego sprzętu.
    • Każdy z modułów jest „centralą” – w końcu w każdej puszce mamy urządzenie sieciowe z interfejsem www – wystarczy, że każde z urządzeń będzie świadome pozostałych w domu i będzie umiało przekazać innym informacje – po zalogowaniu przez www na dowolne urządzenie będzie można sterować całą grupą powiązanych ze sobą włączników.
    • Połączenie dwóch powyższych pomysłów – czyli jeszcze mądrzejszy włącznik – pomysł polega na zaprojektowaniu włącznika, który umożliwiałby sterowanie innymi – miałby wyświetlacz dotykowy i piękny interfejs, dzięki któremu będzie można intuicyjnie sterować wszystkimi włącznikami.
  • Autoryzacja użytkownika – czyli zabezpieczenie, żeby nikt niepowołany nie zgasił nam światła w toalecie. Dlaczego tak późno w planie? Z kilku powodów. Przede wszystkim na sposób autoryzacji będą miały wpływ decyzje odnośnie protokołów do wyszukiwania urządzenia – mają one (lub nie mają) swoje wbudowane mechanizmy zabezpieczania dostępu – nie ma sensu przed implementacją tamtych rozwiązań bawić się w wymyślanie własnych. Druga sprawa to to, że wiele urządzeń sieciowych zakłada, że sieć domowa jest siecią tylko dla „swoich” – jest dobrze zabezpieczona i ten kto ma do niej dostęp – ma też dostęp do urządzeń w niej pracujących. Zwróć, Drogi Czytelniku, uwagę podczas instalacji drukarki sieciowej – nie jesteś pytany ani o login ani o hasło (zazwyczaj). Jeśli pozwalamy intruzom, którzy dostali się do naszej sieci na zużycie naszych oryginalnych tuszy wartych 200 PLN – to chyba możemy im pozwolić na włączenie 3-watowej żarówki (rachunek równy cenie naszych tuszy żarówka taka będzie generować przez kilkanaście lat ciągłego świecenia). Założenie takie jest bardzo wygodne, jednak warto rozważyć (i umieścić w planie) możliwość zabezpieczenia dostępu – sieci lokalne nie są w 100% bezpieczne, nie wszyscy, którzy są w naszej sieci – nawet jeśli powinni mieć dostęp do włączania światła to nie koniecznie do zmiany ustawień naszego włącznika. No i każde nawet najgłupsze zabezpieczenie (jak choćby zabezpieczenie ustawień telefonów Cisco poprzez kod „* * #” 🙂 ) jest lepsze niż jego brak. Oczywiście – należy opanować się i nie implementować weryfikacji certyfikatu klienta z dodatkowym potwierdzeniem kodem z SMS-a. Obecne założenia są takie, że sieć WiFi mamy bezpieczną – i zabezpieczenie w sieci lokalnej służy tylko, żeby kumpel-żartowniś czy mniej świadoma osoba nie zepsuła czegoś w naszej konfiguracji. Co innego implementacja bezpieczeństwa komunikacji z chmurą – ale to już dalszy etap.
  • Komunikacja z chmurą (to właśnie ten etap) – jak już tu dobrniemy – czyli już będziemy mieli piękne urządzenie, które można skonfigurować/obsłużyć zarówno przez interfejs www jak i z aplikacji mobilnej/noszalnej (brzmi głupio – są jakieś lepsze tłumaczenia wearable?) pora na przemyślenie integracji naszej żarówki sufitowej z całym światem. Spora część pracy będzie po stronie aplikacji serwera (zarówno backend jak i frontend), ale również pewne zmiany będą musiały być poczynione w naszym firmwarze. Przede wszystkim będzie trzeba zaprojektować połączenie z serwerem w internecie – nie wchodzi w grę nasłuch na portach (wymagało by to zaawansowanej konfiguracji przekierowania portów przez użytkownika – a pamiętamy, ze nasze urządzenie ma być przyjazne osobom atechnicznym). Pozostaje polling (odpytywanie co określony czas) serwera albo utrzymanie stałego połączenia TCP. Drugie rozwiązanie, choć trudniejsze w implementacji, wydaje się lepsze – ze względu na szybszy czas reakcji naszej żarówki jak i ilość danych (po zestawieniu połączenia tylko niewielkie ilości danych muszą być przesyłane). Pozostaje też kwestia bezpieczeństwa danych, które każdy może podsłuchać. Szyfrowanie nie wydaje się konieczne, ale odpowiednie uwierzytelnianie (żeby nie było możliwym podszycie się pod naszą żarówkę ani pod nasz serwer internetowy). rozwiązania są gotowe – https z weryfikacją certyfikatu serwera – pytanie czy prostym będzie zaimplementowanie szyfrowania na komputerze wielkości znaczka pocztowego. Jeśli nie – trzeba będzie uprościć komunikację.
  • Bajery i gadżety. Obsługa wszystkich dodatkowych opcji – fotorezystor do badania jak jest jasno (lub ciemno) – czyli funkcja włącznika zmierzchowego, mikrofon ze wzmacniaczem (włączanie na klaski), LED-y (w tym RGB), czujniki ruchu, termometry i inne rozwiązania, które łatwo będzie wdrożyć pod warunkiem, że uda nam się zrobić ładny modułowy kod firmware’u. Proszę trzymać kciuki :).

Software

No i czas na najbardziej programistyczną część projektu – czyli wszelaki software. Tu pozwolę sobie plan skonstruować później. Dużo jeszcze decyzji do podjęcia i od nich zależeć będzie plan działania. Zamiast planu zatem – koncert życzeń.

Życzyłbym sobie, żeby aplikacja kliencka działała na moim smartfonie (Android). Miałaby ona łączyć się ze wszystkimi modułami bezpośrednio, jeśli telefon jest akurat w sieci lokalnej, jednak również ta sama aplikacja mogłaby zarządzać modułami poprzez naszą chmurkę, jeśli jesteśmy akurat w innym województwie. Fajnie by było, żeby projekt był uniwersalny i działał na różnych platformach (może warto zastanowić się nad Apache Cordova) jednak chciałbym również, żeby wyłączenie/włączenie światła było możliwe na moim zegarku z Android wear – a nie wiem na ile jest to możliwe z przypadku aplikacji w cordovie. Następny temat to oprogramowanie chmury. Znam dobrze PHP – i najprościej byłoby w tej technologii zrobić serwer z logowaniem użytkowników, bazą w MySQL, rejestrowaniem modułów itp. Tylko po co ma być najprościej :-). Jak już wspomniałem w celu uniknięcia pollingu (oraz w celu możliwości działania za NAT-em) konieczne jest stałe utrzymywanie stałego połączenia TCP. Jeśli dodać do tego kolejne założenie, że nie ma być dodatkowej centrali – tworzy to sporo równoległych połączeń TCP. Być może jest to dobra okazja aby zaprzyjaźnić się z Node.js, który, przynajmniej z pobieżnego rozpoznania powinien sobie poradzić z mnóstwem konkurencyjnych połączeń.

Na pewno etap  podłączania naszego włącznika do internetu będzie największym wyzwaniem. Pod uwagę trzeba wziąć bezpieczeństwo, szybkość działania, skalowalność itp. etap ten będzie ingerencją w firmware, software (aplikacja mobilna również powinna móc sterować naszym urządzeniem z internetu jeśli połączenie bezpośrednie nie jest dostępne) oraz oprogramowanie serwerowe. Na pewno nie jestem jedynym, który się za ten temat bierze – przegląd istniejących rozwiązań również powinien się znaleźć w planie.

Uffff

Koniec przydługiej próby zaplanowania sobie pracy. Chaos :). Na pewno wszystko jeszcze mnóstwo razy się zmieni – ale mamy już punkt wyjścia. Jest co zmieniać. Obiecuję, że następny wpis będzie krótszy i będzie też zawierał obrazki i zdjęcia. Jako, że konkurs programistyczny, który jest motorem napędowym tego projektu, do oceny bierze tylko posty z czasu trwania konkursu (od 1 marca do 31 maja 2016), to do tego czasu wstrzymam się z działalnością programistyczną a zajmę sprzętem – w następnym wpisie będą supły i pająki – czyli konstruowanie prototypów :).

Oto zapowiedź:

lampa3 lampa2 lampa

Drodzy czytelnicy (jest tam ktoś?) – do trzech razy sztuka – trzymajcie kciuki, żeby blog nie umarł po drugim wpisie.

Dodaj komentarz