Dziś kolejny odcinek o tym co i jak można wyczarować w SmartFonie ala Smart Home.
Wrócę jeszcze na chwilę do postępu technologicznego w informatyce. Technologicznego to znaczy związanego ze sprzętem a nie z oprogramowaniem mikrokontrolerów czy ogólnie procesorów. Czasami warto to zrobić gdy np. wkurza mnie wolno uruchamiający się BLYNK w telefonie.
Wrócę jeszcze na chwilę do postępu technologicznego w informatyce. Technologicznego to znaczy związanego ze sprzętem a nie z oprogramowaniem mikrokontrolerów czy ogólnie procesorów. Czasami warto to zrobić gdy np. wkurza mnie wolno uruchamiający się BLYNK w telefonie.
W 1969 (prawie pół wieku temu) pierwsze lądowanie człowieka na księżycu "wspierał" komputer statku Appolo z zegarem 2 MHz i 4 kB pamięci RAM! Rakieta kosmiczna sterowana byla przez Arduino UNO !!!! ( 16 MHz 2 KB RAMu)
Jeszcze smakowitsze jest zestawienie superkomputera CRAY 2 1985 roku (244 MHz i 1,9 G Flops mocy obliczeniowej) z np. Samsung Galaxy S6 ( 2100 MHz i 35 G Flops). IPhone 4 wypada w tym zestawieniu raczej blado!
Postęp w mikroelektronice jest nieprawdopodobny a prawo Moora napędza go wciąż bez umiaru.
Pytam się co przez te pół wieku robili programiści, że muszę czekać 10 - 20 sek sekund na uruchomienie się co bardziej złożonych telefonicznych aplikacji?
Nic dziwnego, że "prawdziwi" elektronicy traktują jako wielką zakałę współczesnej informatyki wszelkiej maści programistów. I moim zdaniem całkiem słusznie. Mentalnie podobni są do kobiet. Nie ma takiego superkomputera którego nie da się zamulić źle napisanym kodem podobnie jak nie ma takiej sumy pieniędzy na koncie której nie potrafi wydać prawdziwa kobieta.
Ale bez kobiet i programistów ten świat nie byłby tak piękny i kolorowy. Co widać dobitnie w telefonicznych programach.
Wracam więc do kolejnego opisu aplikacji VIRTUINO.
Po pierwsze gorąco zachęcam do wydania 50 zł na wersję VIRTUINO PRO. Jak to ktoś kiedyś napisał o BLYNKu - "warto wspierać dobre projekty". O VIRTUINO jest to prawdziwe na 200%. Najważniejsze ,że bezterminowo i bez żadnych ograniczeń kupujemy dostęp do wszystkich możliwości konfiguracyjnych projektu. A jest ich naprawdę sporo i oferują pełną "profesjonalizację" produktu w celach komercyjnych. Za 50 zł!
O takich drobiazgach jak możliwość tworzenia własnych widgetów nawet nie wspominam.
Po drugie projekt rozwija się tak szybko, że nie mam szans opisać tu na bieżąco wszystkich interesujących zmian. Właśnie ukazały się kolejne mutacje telefonicznych/ tabletowych aplikacji
I pomyśleć, że to robota dwóch osób. Fenomenalne. Nad BLYNKiem na stałe pracuje 8 osobowy team.
I BLYNK i VIRTUINO to tak naprawdę panele HMI (Human Machine Interface) czyli po naszemu pulpity sterownicze. A więc (w teorii) potrzebne tylko wtedy gdy znajduje się przy nim człowiek. Gdy człowiek idzie na piwo panel powinien być w stanie OFF ale sterowane z niego urządzenie musi działać nadal autonomicznie i bez zakłóceń. W BLYNKu tak rzeczywiście jest - aplikacja jest tyko wizualizacją stanów w serwerze BLYNKa więc jej wyłączenie nie ma wpływu na pracę układu serwer - moduły.
W VIRTUINO sprawa się nieco komplikuje. Jeśli używamy aplikacji jedynie do podglądu stanów mikrokontrolera (mikrokontrolerów) wszystko jest Ok. Wyłączenie aplikacji urywa komunikację telefon - mikrokontroler ale nie zakłóca w niczym pracy tego ostatniego. Ale pomysłodawca systemu przyjął ambitny cel stworzenia z aplikacji nie tylko ładnego i przyjaznego pulpitu ale zaopatrzył go w typowe funkcje serwera IoT.
Mój ulubiony schemat IoT to rozproszone po domu moduły realizujące pojedyncze funkcje i kontaktujące się między sobą radiową siecią WiFi lub 433 MHz na terenie posesji. Budowa jednego ale rozproszonego systemu przy pomocy BLYNKa nie nastręcza żadnych problemów. Jest to typowa topologia gwiazdy z serwerem BLYNK jako punktem centralnym systemu.
Czy mogę zbudować zintegrowany system rozproszonych sterowników za pomocą VIRTUINO. Tak i to na kilka sposobów choć wymaga to nieco więcej zachodu.
Jak na razie znalazłem trzy różne sposoby rozwiązań by uzyskać żądaną architekturę sterowania. Wszystkie sposoby są "zaszyte" w VIRTUINO należy je tylko inteligentnie wykorzystać.
Standardowo VIRTUINO przeznacza mikrokontrolerom funkcję serwera. Jak to działa dokładniej opisałem tutaj.
Klientami w systemie są telefoniczne aplikacje cyklicznie przepytujące układy mikroprocesorowe. Tak zbudowany system nie jest właściwie systemem - to zbiór kilku niezależnych mikroprocesorów "obserowanych" przy użyciu tej samej konsoli sterowniczej. I tak naprawdę powyższy system nie ma większego sensu. Jeśli obie aplikacje są nieaktywne czujnik temperatury (i wilgotności) DHT11 nie ma szans w żaden sposób sterować przekaźnikami w pozostałych układach.
Ale prosta zamiana funkcji w kodzie mikrokontrolera z serwera na klienta tworzy nam bezpośrednie powiązania pomiędzy urządzeniami naszego systemu. Czujnik przekazuje pomierzone wartości wprost do przekaźników a zaszyte w układach zależności realizują odpowiednie funkcje sterowania. Co ważne wszystko to możemy kontrolować z poziomu aplikacji bo te połączone są z modułami przekaźników.
Generalna zasada dla takiej topografii sieci jest taka, że moduły z czujnikami są klientami VIRTUINO zaś moduły wykonawcze jego serwerami. Aplikacje standardowo pełnią rolę klientów.
Moim zdaniem to optymalna struktura sterowania dla domowej automatyki. Podstawowa zaleta to brak serwera a więc elementu najbardziej wrażliwego na prawidłowe działanie systemu. Inna to, że mamy w zasadzie kilka niezależnych podsystemów, które możemy w razie potrzeby dowolnie łączyć na poziomie pojedynczych urządzeń. Np czujka ruchu może obsługiwać i podsystem alarmowy i załączania świateł przy czym oba te systemy pracują całkowicie niezależne od siebie.
Czy taki układ ma wady. W zasadzie nie. Wydaje się iż pewną trudnością może być konfiguracja struktury i powiązań między układami w sieci. Przez fakt iż klienci muszą mieć na sztywno wpisany adres docelowego serwera (serwerów) ewentualna zmiana wewnętrznej konfiguracji sieci wymaga grzebania w kodzie mikrokotrolerów typu klient. Ale i z tym można sobie poradzić. Trzeba tylko otworzyć mikrokontroler typu klient do współpracy z aplikacją. No ale wtedy klient musiałby stać się serwerem. Oczywiście. Można jednocześnie odpalić klienta i serwera na tym samy procesorze. I dostajemy wtedy taki schemat komunikacji.
W tym przykładzie moduł z DHT11 jest jednocześnie klientem obu modułów przekaźnikowych i serwerem dla aplikacji. Co to nam daje? Możliwość zdalnej konfiguracji klienta czujnika z telefonu. Proste? Nie za bardzo ale daje się to ogarnąć. Przykłady kodu jak to zrobić zamieszczę niebawem.
2. Aplikacja jako główny serwer systemu
Po pierwsze gorąco zachęcam do wydania 50 zł na wersję VIRTUINO PRO. Jak to ktoś kiedyś napisał o BLYNKu - "warto wspierać dobre projekty". O VIRTUINO jest to prawdziwe na 200%. Najważniejsze ,że bezterminowo i bez żadnych ograniczeń kupujemy dostęp do wszystkich możliwości konfiguracyjnych projektu. A jest ich naprawdę sporo i oferują pełną "profesjonalizację" produktu w celach komercyjnych. Za 50 zł!
O takich drobiazgach jak możliwość tworzenia własnych widgetów nawet nie wspominam.
Po drugie projekt rozwija się tak szybko, że nie mam szans opisać tu na bieżąco wszystkich interesujących zmian. Właśnie ukazały się kolejne mutacje telefonicznych/ tabletowych aplikacji
- Virtuino Viewer - umożliwiający pracę w systemie bez możliwości zmian konfiguracyjnych
- Virtuino MQTT - możliwość współpracy z dowolnym brokerem MQTT - tym sposobem uzyskamy funkcjonalność praktycznie identyczną z BLYNKiem czy innymi systemami IoT z centralnym serwerem systemowym
- Virtuino Modbus - praca z profesjonalnymi urządzeniami automatyki w przemysłowym standardzie komunikacji RS232 lub RS485
- Virtuino SE - nowa edycja Virtuino dla projektantów systemów umożliwiająca jeszcze łatwiejszą budowę struktur IoT w oparciu o uproszczony protokół komunikacji (tylko piny wirtualne i dowolne dane przesyłane jako String) i zwiększoną liczbę wirtualnych pinów do 128
I pomyśleć, że to robota dwóch osób. Fenomenalne. Nad BLYNKiem na stałe pracuje 8 osobowy team.
I BLYNK i VIRTUINO to tak naprawdę panele HMI (Human Machine Interface) czyli po naszemu pulpity sterownicze. A więc (w teorii) potrzebne tylko wtedy gdy znajduje się przy nim człowiek. Gdy człowiek idzie na piwo panel powinien być w stanie OFF ale sterowane z niego urządzenie musi działać nadal autonomicznie i bez zakłóceń. W BLYNKu tak rzeczywiście jest - aplikacja jest tyko wizualizacją stanów w serwerze BLYNKa więc jej wyłączenie nie ma wpływu na pracę układu serwer - moduły.
W VIRTUINO sprawa się nieco komplikuje. Jeśli używamy aplikacji jedynie do podglądu stanów mikrokontrolera (mikrokontrolerów) wszystko jest Ok. Wyłączenie aplikacji urywa komunikację telefon - mikrokontroler ale nie zakłóca w niczym pracy tego ostatniego. Ale pomysłodawca systemu przyjął ambitny cel stworzenia z aplikacji nie tylko ładnego i przyjaznego pulpitu ale zaopatrzył go w typowe funkcje serwera IoT.
Mój ulubiony schemat IoT to rozproszone po domu moduły realizujące pojedyncze funkcje i kontaktujące się między sobą radiową siecią WiFi lub 433 MHz na terenie posesji. Budowa jednego ale rozproszonego systemu przy pomocy BLYNKa nie nastręcza żadnych problemów. Jest to typowa topologia gwiazdy z serwerem BLYNK jako punktem centralnym systemu.
Czy mogę zbudować zintegrowany system rozproszonych sterowników za pomocą VIRTUINO. Tak i to na kilka sposobów choć wymaga to nieco więcej zachodu.
Jak na razie znalazłem trzy różne sposoby rozwiązań by uzyskać żądaną architekturę sterowania. Wszystkie sposoby są "zaszyte" w VIRTUINO należy je tylko inteligentnie wykorzystać.
- Mikrokontrolery w roli klient - serwer
- Aplikacja jako główny serwer systemu
- Dołączenie VIRTUINO do zewnętrznego serwera MQTT
Ad.1 Mikrokontrolery w roli klient - serwer
Standardowo VIRTUINO przeznacza mikrokontrolerom funkcję serwera. Jak to działa dokładniej opisałem tutaj.
Klientami w systemie są telefoniczne aplikacje cyklicznie przepytujące układy mikroprocesorowe. Tak zbudowany system nie jest właściwie systemem - to zbiór kilku niezależnych mikroprocesorów "obserowanych" przy użyciu tej samej konsoli sterowniczej. I tak naprawdę powyższy system nie ma większego sensu. Jeśli obie aplikacje są nieaktywne czujnik temperatury (i wilgotności) DHT11 nie ma szans w żaden sposób sterować przekaźnikami w pozostałych układach.
Ale prosta zamiana funkcji w kodzie mikrokontrolera z serwera na klienta tworzy nam bezpośrednie powiązania pomiędzy urządzeniami naszego systemu. Czujnik przekazuje pomierzone wartości wprost do przekaźników a zaszyte w układach zależności realizują odpowiednie funkcje sterowania. Co ważne wszystko to możemy kontrolować z poziomu aplikacji bo te połączone są z modułami przekaźników.
Generalna zasada dla takiej topografii sieci jest taka, że moduły z czujnikami są klientami VIRTUINO zaś moduły wykonawcze jego serwerami. Aplikacje standardowo pełnią rolę klientów.
Moim zdaniem to optymalna struktura sterowania dla domowej automatyki. Podstawowa zaleta to brak serwera a więc elementu najbardziej wrażliwego na prawidłowe działanie systemu. Inna to, że mamy w zasadzie kilka niezależnych podsystemów, które możemy w razie potrzeby dowolnie łączyć na poziomie pojedynczych urządzeń. Np czujka ruchu może obsługiwać i podsystem alarmowy i załączania świateł przy czym oba te systemy pracują całkowicie niezależne od siebie.
Czy taki układ ma wady. W zasadzie nie. Wydaje się iż pewną trudnością może być konfiguracja struktury i powiązań między układami w sieci. Przez fakt iż klienci muszą mieć na sztywno wpisany adres docelowego serwera (serwerów) ewentualna zmiana wewnętrznej konfiguracji sieci wymaga grzebania w kodzie mikrokotrolerów typu klient. Ale i z tym można sobie poradzić. Trzeba tylko otworzyć mikrokontroler typu klient do współpracy z aplikacją. No ale wtedy klient musiałby stać się serwerem. Oczywiście. Można jednocześnie odpalić klienta i serwera na tym samy procesorze. I dostajemy wtedy taki schemat komunikacji.
W tym przykładzie moduł z DHT11 jest jednocześnie klientem obu modułów przekaźnikowych i serwerem dla aplikacji. Co to nam daje? Możliwość zdalnej konfiguracji klienta czujnika z telefonu. Proste? Nie za bardzo ale daje się to ogarnąć. Przykłady kodu jak to zrobić zamieszczę niebawem.
2. Aplikacja jako główny serwer systemu
Jak pisałem Ilias zaprojektował telefoniczną aplikację nie tylko jako prosty HMI ale dodał do niej ciekawe funkcje serwerowe pozwalające zrobić z niej coś na kształt głównego serwera systemu. Prawie serwer? Tak. Pod jednym warunkiem. Aplikacja będzie bez przerwy aktywna!!! Czy taka sytuacja jest w ogóle możliwa. Z telefonem jako pulpitem będzie ciężko. Ale jeśli planujemy w naszym systemie umieścić stały pulpit wiszący na ścianie, z którego można obserwować i sterować całym domowym IoT to czemu nie. Taki pulpit w postaci taniego androidowego tabletu ma sporo zalet. I jedną wadę - nieuważna jego obsługa może przez przypadek wyłączyć nam aplikację i mamy po systemie. Albo długotrwały zanik napięcia zasilania wyłączy tablet bez możliwości automatycznego powrotu do aplikacji VIRTUINO.
Jest więc kilka ALE przy konstruowaniu sieci tego typu ale jest i sporo zalet. Największą jest sama aplikacja VIRTUINO dająca nam spore (w porównaniu z BLYNKiem) możliwości konfigurowania systemu. W wersji rozszerzonej (PRO) tablet może jednocześnie być klientem jak i serwerem systemu. To praktycznie zdejmuje wszelkie ograniczenia przy tworzeniu struktury powiązań pomiędzy modułami w systemie. Może być ona dowolna. Przywracamy więc do życia pierwszy ze schematów ale tym razem jedna z aplikacji a nie jest już prostym panelem HMI ale pełnoprawnym serwerem systemu. Druga i dalsze aplikacje są tu jedynie klientami również stosunku do aplikacji-serwera. To bardzo ciekawy i mocno rozwojowy schemat systemu
Główna funkcja serwera BLYNK to inteligentne połączenie łączenie modułu/ów i aplikacji oraz przechowywanie danych.W VIRTUINO połączenie aplikacji z modułem jest bezpośrednie a dane mogą być przechowywane zarówno w module jak i w aplikacji. Zaawansowane serwery pozwalają również na tworzenie zależności funkcjonalnych pomiędzy sygnałami krążącymi w systemie. Od jakiegoś czasu funkcja taka pod nazwą EVENTOR jest dostępna również w BLYNKu. Ale jej implementacja jest więcej niż skromna i sprowadza się w zasadzie do prostej funkcji "if" i to dla pojedynczych wielkości. O tworzeniu złożonych powiązań wielu sygnałów z użyciem dowolnych funkcji matematycznych czy logicznych jak jest to dostępne choćby w serwerze NODE RED nie ma co marzyć.
Toteż dużym zaskoczeniem dla mnie był szeroki wachlarz tworzenia zależności sygnałów w VIRTUINO. Do dyspozycji dostajemy praktycznie wszystkie funkcje logiczne bez ograniczenia liczby sygnałów wejściowych.
To jeden z mocniejszych atutów aplikacji VIRTUINO jako serwera IoT. O innych możliwościach takiej konfiguracji będzie jeszcze okazja podywagować.
3. Dołączenie do VIRTUINO zewnętrznego serwera MQTT
Wspomniałem o pojawieniu się kolejnych odmian aplikacji VIRTUINO w tym VIRTUINO MQTT. Dzięki temu zwolennicy serwerów centralnych IoT mają dostęp do klasycznej struktury gwiazdy swojego systemu. Obecna wersja udostępnia połączenie z dowolnym brokerem choć polecane są darmowe broker.shiftr.io lub m2m.eclipse.org
Na temat samej technologi połączeń układów IoT za pomocą protokołu MQTT wiem niewiele. Ale podobny poziom wiedzy mam o protokołach BLYNKa czy VIRTUINO i specjalnie mi to nie wadzi by ich skutecznie używać w moich projektach. Z MQTT może być trochę trudniej gdyż próbujemy łączyć urządzenia i programy różnych dostawców a z tym zawsze są jakieś problemy. Ot choćby numer wersji protokołu używany przez obie strony winien być podobny co i tak nie gwarantuje 100% kompatybilności.
MQTT miał być pierwotnie zaimplementowany również w BLYNKu ale jak na razie nie jest.
Natomiast VIRTUINO został przystosowany do komunikacji tym protokołem kompleksowo. To znaczy powstała osobna wersja aplikacji pozwalająca na pełną konfigurację połączeń aplikacji z brokerem.
W modułach zamiast biblioteki VIRTUINO należy załadować bibliotekę MQTT dla ARDUINO.
Przykładowy program klienta dla procesora ESP8266 znajdziemy tutaj >>>
Skromnie, na początku, wyglądająca aplikacja zdaje się kryć w sobie całkiem potężne możliwości zarządzania sieciami IoT. VIRTUINO podoba się mi coraz bardziej.
Główna funkcja serwera BLYNK to inteligentne połączenie łączenie modułu/ów i aplikacji oraz przechowywanie danych.W VIRTUINO połączenie aplikacji z modułem jest bezpośrednie a dane mogą być przechowywane zarówno w module jak i w aplikacji. Zaawansowane serwery pozwalają również na tworzenie zależności funkcjonalnych pomiędzy sygnałami krążącymi w systemie. Od jakiegoś czasu funkcja taka pod nazwą EVENTOR jest dostępna również w BLYNKu. Ale jej implementacja jest więcej niż skromna i sprowadza się w zasadzie do prostej funkcji "if" i to dla pojedynczych wielkości. O tworzeniu złożonych powiązań wielu sygnałów z użyciem dowolnych funkcji matematycznych czy logicznych jak jest to dostępne choćby w serwerze NODE RED nie ma co marzyć.
Toteż dużym zaskoczeniem dla mnie był szeroki wachlarz tworzenia zależności sygnałów w VIRTUINO. Do dyspozycji dostajemy praktycznie wszystkie funkcje logiczne bez ograniczenia liczby sygnałów wejściowych.
To jeden z mocniejszych atutów aplikacji VIRTUINO jako serwera IoT. O innych możliwościach takiej konfiguracji będzie jeszcze okazja podywagować.
3. Dołączenie do VIRTUINO zewnętrznego serwera MQTT
Wspomniałem o pojawieniu się kolejnych odmian aplikacji VIRTUINO w tym VIRTUINO MQTT. Dzięki temu zwolennicy serwerów centralnych IoT mają dostęp do klasycznej struktury gwiazdy swojego systemu. Obecna wersja udostępnia połączenie z dowolnym brokerem choć polecane są darmowe broker.shiftr.io lub m2m.eclipse.org
Na temat samej technologi połączeń układów IoT za pomocą protokołu MQTT wiem niewiele. Ale podobny poziom wiedzy mam o protokołach BLYNKa czy VIRTUINO i specjalnie mi to nie wadzi by ich skutecznie używać w moich projektach. Z MQTT może być trochę trudniej gdyż próbujemy łączyć urządzenia i programy różnych dostawców a z tym zawsze są jakieś problemy. Ot choćby numer wersji protokołu używany przez obie strony winien być podobny co i tak nie gwarantuje 100% kompatybilności.
MQTT miał być pierwotnie zaimplementowany również w BLYNKu ale jak na razie nie jest.
Natomiast VIRTUINO został przystosowany do komunikacji tym protokołem kompleksowo. To znaczy powstała osobna wersja aplikacji pozwalająca na pełną konfigurację połączeń aplikacji z brokerem.
W modułach zamiast biblioteki VIRTUINO należy załadować bibliotekę MQTT dla ARDUINO.
Przykładowy program klienta dla procesora ESP8266 znajdziemy tutaj >>>
Skromnie, na początku, wyglądająca aplikacja zdaje się kryć w sobie całkiem potężne możliwości zarządzania sieciami IoT. VIRTUINO podoba się mi coraz bardziej.
6
Brak komentarzy:
Prześlij komentarz