Za co lubię VIRTUINO - za to samo. Ilias Lamprou na bazie standardowych bezpłatnych bibliotek <ESP8266WiFi.h> i <Ethernet.h> dodając kilkast linii kodu stworzył program zdalnego sterowania mikrokontrolerem. I udostępnia go za darmo.
Działa? Działa!
I to nie gorzej niż programy zajmujące po wielokroć więcej miejsca i obudowane złożonymi procedurami komunikacji.
Dziś - o komunikacji w ramach VIRTUINO i co z tego wynika
Najpierw wyjaśnienie. VIRTUINO obsługuje trzy media komunikacyjne Bluetooth, Ethernet i WiFi.
Bluetooth to tak naprawdę połączenie typu serial a z punktu widzenia procesora to rodzaj transmisji wykorzystujący sprzętowy lub programowy sprzęg RS232. Ten typ łączności nadaje się znakomicie do sterowania urządzeniem na niewielkie odległości kilku kilkunastu metrów. Ale zbudować złożonego systemu sterowania domem na tym się nie da. Ten rodzaj komunikacji zostawię sobie do analizy na później jako swego rodzaju ciekawostkę.
Połączenie Ethernet wymaga dociągnięcia kabla sieciowego do mikrokontrolera. Do niedawna był to w zasadzie jedyny niedrogi sposób "usieciowienia" domowej automatyki. Dziś w czasach wszechobecnej łączności bezprzewodowej to medium to przeżytek zwłaszcza w miniaturowych i rozsianych po całym domu mikroprocesorowych sterownikach IoT.
Na placu pozostało więc WiFi. A jeśli WiFi to chiński przebój ESP8266/32. I taka konfiguracja sprzętowo komunikacyjna czas jakiś będzie podstawą dalszych analiz VIRTUINO.
Podstawą działania całego systemu VIRTUINO jest uruchomiony w mikroprocesorze serwer WWW. Musi być co najmniej jeden. Ale może być ich znacznie, znacznie więcej tworząc całkiem sporą sieć inteligentnego domu zarządzaną z androidowej aplikacji. Można też do serwera WWW zainstalowanego w jednym mikrokontrolerze przyłączyć klientów umieszczonych w innych modułach. Tym sposobem stworzenie sieci typu MESH jest w VIRTUINO w zasięgu ręki.
W najprostszej konfiguracji w każdym procesorowym module instalowany jest serwer WWW. Klientem / klientami serwera są telefoniczne aplikacje VIRTUINO. Teoretycznie klientów a więc paneli zarządzania systemem może być dowolna ilość. Teoretycznie. Praktyka jak to praktyka "nieco' różni się od teorii i liczba kilkunastu klientów przyłączonych do jednego serwera możne okazać się zbyt dużym obciążeniem serwera. Wszystko zależy od ilości przesyłanych danych i częstotliwości odpytywania serwera przez poszczególnych klientów. Ale trudno też sobie wyobrazić sytuację gdy w domu znajduje się więcej niż 2-3 panele sterujące automatyką. Liczba kilkunastu jest więc też mocno teoretyczna.
Powyższy schemat pokazuje kilka ciekawych cech VIRTUINO
Tak zbudowany system sterowania nie jest par excellence (Kwinto przywrócił tę frazę do życia) systemem. Jest złożeniem kilku niezależnych par bezprzewodowego sterowania mikroprocesor - aplikacja zainstalowanych w ramach tych samych urządzeń. I to złożeniem dosyć luźno powiązanych elementów. Każdą więc parę klient - serwer należy konfigurować i analizować niezależnie od siebie. Co to oznacza w praktyce?
VIRTUINO sprawdzi się świetnie zarówno w zcentralizowanych sterowaniach domem gdzie jeden wieloportowy i wielokanałowy układ mikroporcesorowy poprzez dziesiątki metrów kabli zarządza domową automatyką. Tu jedna lub kilka aplikacji łączy się z takim mikrokontrolerem i zarządza nim w ramach zaprogramowanych w telefonie / tablecie funkcji. Pomimo podstawowej wady takiego rozwiązania - wrażliwości całego systemu na awarię jedynego modułu araz trudności z przeprogramowaniem funkcji - jest to dość popularny schemat domowej automatyki.
Ale jeszcze lepiej możliwości VIRTUINO zostaną wykorzystane w systemach rozproszonych gdzie każdy z mikrokontolerów realizuje swoją jedną małą funkcję IoT - steruje bramą garażową, piecem CO, mierzy temperaturę w pomieszczeniu, podlewa ogród, zapala światło w kuchni lub lampki na choince.
Jak widać ze schematu połączeń program jest w sposób naturalny przystosowany do obsługi niezależnych od siebie podsystemów funkcjonujących w obrębie tej samej nieruchomości (czytaj w ramach tej samej sieci WiFi). Elementem integrującym taki rozproszony system jest pulpit sterujący telefonicznej aplikacji. To z niego jednym przyciskiem można wyłączyć wszystkie sterowane źródła światła, zamknąć garaż i włączyć system alarmowy mimo, iż żaden z tych systemów "nie wie" o istnieniu drugiego. Tak zbudowany system jest całkowicie odporny na uszkodzenia poszczególnych elementów. Awaria mikrokontrolera sterowania rolet jest bez znaczenia dla funkcji sterowania bramą garażową. Nawet wyłączenie czy zawieszenie aplikacji nie ma żadnego wpływu na poszczególne funkcje, które są nadal realizowane w obrębie działających niezależnie mikrokontrolerów. Podobnie jak awaria domowej sieci WiFi nie spowoduje np. wyłączenia sterowania pieca CO co mogło by zmrozić niejednego miłośnika Smart Home.
Drugą fajną cechą VITUINO jest swoboda konfiguracji każdego z paneli aplikacji. Każda aplikacja w telefonie czy tablecie jest niezależnym od innych elementem sterowania i może być połączona z wybranymi dowolnie elementami systemu. Można więc bez problemu stworzyć sobie panel "światła i ogrzewanie" na tablecie w salonie i "ochrona" na tablecie przy wyjściu z domu. Oba te panele mogą zarządzać tymi samymi zasobami (czujką ruchu, sterowanym światłem czy kotłem CO) ale wykorzystywać je do swoich celów. Panel w salonie zadba o właściwą temperaturę i włączy światło gdy wyczuje ruch w pomieszczeniu, panel przy wyjściu wyłączy wszystkie światła, zmniejszy temperaturę pomieszczeń i podłączy czujki ruchu do sygnalizacji alarmowej gdy będziemy opuszczać dom. Co umieścimy w telefonie - przenośnym pulpicie sterowania domem - zależy już tylko od naszej fantazji.
Dla systemów rozproszonych elastyczność VIRTUINO jest wprost zadziwiająca. Nie znam drugiego takiego systemu pozwalający w dowolny sposób i bez żadnych ograniczeń kształtować strukturę wewnętrzną systemu sterowania i wynikające stąd funkcjonalności.
Niestety jest jeden minus takiej konstrukcji. Wraz ze wzrostem liczby serwerów i liczby klientów ruch w sieci rośnie w postępie geometrycznym i to bez względu na ilość ewentualnych danych jakie należy wymienić pomiędzy urządzeniami. W strukturze klient-serwer większość ramek jest pustych i służy jedynie sprawdzeniu czy serwer nie ma czegoś do wysłania do klienta. Dlaczego?
Jak już wspominałem w układzie klient - serwer opartym na technologii WWW transmisję ZAWSZE inicjuje (rozpoczyna) klient. W VIRTUINO robi to w dwu przypadkach:
- musi coś akurat wysłać do serwera a przy okazji dołącza do wysyłanej wiadomości ramkę z zapytaniem o aktualny stan wybranych zmiennych w mikrokontrolerze
- w określonych interwałach czasu wysyła pustą ramkę z zapytaniem o stan wybranych zmiennych
A co robi serwer? Nic, czeka. Jeśli żądanie od klienta nie nadchodzi serwer jest niemy a mikroprocesor wykonuje swoje lokalnie działania, w tym przygotowuje dane dla klienta gdy ten w końcu zechce się odezwać. Jeśli klient z jakiegokolwiek powodu nie może nawiązać połączenia z serwerem nie ma to żadnego wpływu na prawidłową prace procesora. Nie ma więc możliwości zawieszenia są programu z powodu np. awarii sieci WiFi jak ma to miejsce w innych systemach. VIRTUINO jest całkowicie odporne na tego typu zdarzenia.
Jakie dane przesyłane są między klientem a serwerem zależy TYLKO od klienta. Dokładniej, dowiązanie do widgetu aplikacji pinu rzeczywistego lub wirtualnego automatycznie umieszcza go w ramce wiadomości. I tylko te dane będa wymieniane między aplikacją a urządzeniem.
Jeśli podstawą działania VIRTUINO jest zainstalowany w mikrokontrolerze serwer WWW to podstawą komunikacji musi być protokół HTTP. Każdy klient musi umieć wysłać poprawny nagłówek HTTP wersji 1.1 zawierający w treści dane przesyłanych pinów lub żądanie ich wysłania przez serwer. Nie jest to zbyt skomplikowana procedura i można ją podejrzeć w kliencie mikroprocesora.
Autor programu stworzył własny prosty protokół wymiany danych bardzo podobny do metody GET HTTP. Nie będę go szczegółowo opisywał, wszelkie informację są dostępne tutaj >>>>>. Warto tylko zauważyć iż każda dana rozpoczyna się ! a kończy znakiem $. Ponadto w treści wysyłanego przez klienta żądania zawarte jest słowo GET, którego nie ma w odpowiedzi serwera.
Jeśli w konfiguracji VIRTUINO ustawiliśmy hasło pojawia się ono każdym żądaniu od klienta. Hasło to ma za zadanie jednoznacznie zdefiniować odbiorcę wysyłanej wiadomości.
Z opisu protokołu wynika, iż można nim kontrolować (ustawiać i czytać) zarówno porty mikrokontrolera (tzw. piny rzeczywiste) jak i zmienne w programie (piny wirtualne).
Poniżej przykład przesyłanych danych wyświetlonych monitorem w mikroprocesorze
I takie to ramki wiadomości krążące między klientem a serwerem są podstawą komunikacji w całym systemie. Wadą tego rozwiązania jest to, iż muszą być one generowane permanentnie i często by komunikacja odbywała się w sposób niezakłócony i bez zbędnych opóźnień.
Ale cóż prostota systemu VIRTUINO ma swoje plusy dodatnie i ujemne minusy.
Przydatne linki
- Opis protokołu VIRTUINO http://virtuino.com/index.php/documentation/command-format
- Kod klienta VIRTUINO z procedurami generowania żądania HTTP http://virtuino.com/downloads/examples/virtuino_client_nodemcu.zip
3
Brak komentarzy:
Prześlij komentarz