Wiadomo już mniej więcej jak zaadresować przesyłki w BLYNKu za pomocą AUTH by docierały tam gdzie zamierzamy je wysłać.
Osobną kwestią jest czy przesyłka rzeczywiście dotrze do adresata i czy nadawca dowie się o tym fakcie. To nasz codzienny dylemat gdy wysyłamy emaila. Naciśnięcie przycisku WYŚLIJ niczego nam jeszcze nie gwarantuje - to raczej nadzieja na to, że ktoś po drugiej stronie odczyta naszą wiadomość. Gdy bardzo zależy nam dotarciu do adresata prosimy go o potwierdzenie otrzymania wiadomości.
W grze w totolotka nadzieja jest podstawowym mechanizmem napędzającym tą zabawę - w automatyce czy sterowaniu to zdecydowanie za mało. Oczekujemy przynajmniej 100% pewności a czasami i większej.
Czy BLYNK daje nam taki poziom zaufania w naszych systemach IoT?
BLYNK to Internet a z internetem bywa różnie. I choć protokół TCP/IP teoretycznie gwarantuje prawidłową wysyłkę i odbiór całości nadawanej informacji to jednak w przypadku fizycznego braku połączenia pomiędzy urządzeniami lub wyłączenia któregoś z nich wszystkie mechanizmy kontroli przepływu danych zdadzą się na nic.
Prawdopodobieństwo dostarczenia wiadomości jest bardzo duże gdy sprawdzimy dostępność urządzeń przed jej wysłaniem. Jeśli urządzenia "widzą" się w internecie to protokół TCP/IP zadba już o prawidłowe przesył danych. Jeśli jedno z urządzeń jest w danej chwili nie dostępne ważne jest zachowanie wysyłanej informacji do momentu przywrócenie wzajemnej komunikacji. I takie podstawowe działania ma w sobie zaszyte BLYNK.
Najłatwiej powinno być z aplikacją mobilną w telefonie. Powinno ... Jakakolwiek przyczyna braku połączenia z serwerem skutkuje zawsze tym samym - nasza aplikacja się nie uruchomi. I nie ma znaczenia czy jest to
- brak Internetu (czasami)
- brak dostępności serwera BLYNK (jeszcze tak nie było)
- źle wpisane dane do logowania do aplikacji (b. często)
- przestawiony przełącznik serwera publiczny/prywatny (b. często)
Oczywiście niczego w urządzeniu nie wysterujemy ale tego nie stwierdzimy obserwując jedynie ekran aplikacji. Patrząc na ekran telefonu nie jesteśmy do końca pewni czy system pracuje czy też nie. Jeśli w naszym programie nic się nie dzieje to o braku połączenia dowiemy się dopiero przy próbie ponownego otwarcia aplikacji. Przywrócenie połączenia z serwerem też nie następuje natychmiast . Musi upłynąć kilkanaście sekund zanim APP ponownie synchronizuje swoje dane. To ogromny minus w działaniu BLYNKa. Dziurę tę musimy załatać sobie sami - jak? - opis w następnym wpisie.
Ważne jest by po ponownym nawiązaniu połączenia aplikacja zawierała aktualne informacje o stanach zmiennych w urządzeniu. Tak będzie jeśli do komunikacji mikroprocesor - aplikacja mobilna będziemy używali procedury Blynk.virtualWrite (Vx, dana) zapisujących dane na serwerze BLYNK. Z chwilą przywrócenia łączności APP-serwer aktualne wartości pinów zostaną wysłane z serwera do aplikacji mobilnej.
Trochę lepiej jest z kontrolą połączenia pomiędzy aplikacją a urządzeniem. Jeśli nasz moduł (moduły) jest niedostępny dla serwera jest to sygnalizowane w aplikacji. Należy nacisnąć ikonę procesora w prawym górnym rogu bu ukazał się spis wszystkich modułów przypisanych do projektu w raz z mikroskopijną kropką sygnalizującą ich stan połączenia. Zielona - działa, szara nie działa.
Sprawdzanie połączenia oparte jest na cyklicznym wysyłaniu pakietów kontrolnych przez bibliotekę BLYNKa w urządzeniu (tzw HEARTBEAT) z częstością co 10 sek. Częstotliwość wysyłania można zmienić w kodzie biblioteki BLYNK nadając nową wartość stałej #define BLYNK_HEARTBEAT 10 lub w kodzie programu poprzez Blynk.config poleceniem newHeartbeatInterval*2.3. Serwer oczekuje 15 sek na pojawienie się kolejnej transmisji z urządzenia. Po tym czasie wobec braku aktywności ustawia flagę urządzenia na OFFLINE. I ta flaga gasi lub zapala kropeczkę w aplikacji telefonu. 15 sekundowy czas oczekiwania serwera też możemy zmienić w pliku server.properties.
To niezbyt czytelny i wygodny sposób sprawdzania połączeń w systemie - i to tylko połączeń w jedną stronę - od urządzenia do serwera.
Z punktu widzenia urządzenia sprawa przedstawia się nieco inaczej. W zależności od funkcji jaką spełnia BLYNK w systemie połączenie z serwerem może mieć znaczenie kluczowe lub drugorzędne. W typowych systemach IoT gdzie wszelkie funkcje wymagają stałego dostępu do serwera (np. cały program działania zapisany jest na serwerze) sprawne połączenie jest priorytetem. W przypadku jego braku podstawowe działanie systemu jest zawieszone a jedyną funkcję jaką realizuje układ jest sygnalizacja braku połączenia i próba ponownego jego zestawienia.
I tak w podstawowej konfiguracji działa BLYNK jeśli jest standardowo uruchomiony w mikroprocesorze za pomocą dwu funkcji
Blynk.begin(auth);
Blynk.run();
Przy braku połączenia biblioteka BLYNKa ciągle podejmuje próbę nawiązania łączności nie dopuszczając "do głosu" pozostałej części naszego programu (program staje na procedurze Blynk.begin). Na filmie biblioteka próbuje w kółko łączyć się z serwerem BLYNK pod adresem 192.168.2.19. Gdy program jest głównej pętli programu (LOOP()) procedura Blynk.run. podejmuje próby połączenia z serwerem z rzadka i niechętnie oddając sterowanie innym procedurom programu. W efekcie utrata połączenia praktycznie zawiesza normalne działanie głównej części kodu. Co widać na filmie - program powinien co sekundę wysyłać temperaturę na port szeregowy i tak jest jedynie w przypadku prawidłowego połączenia z serwerem BLYNK.
W przykładzie przerwałem połączenie poprzez wyłączenie lokalnego serwera. W praktyce taki stan następuje zwykle przy zerwaniu połączenia mikroprocesora z Internetem co zdarza się stosunkowo często.
W systemach autonomicznych realizujących zaprogramowane funkcje niezależnie od BLYNKa taka sytuacja jest absolutnie niedopuszczalna. Regulacji temperatury w naszym domu czy w działaniu systemu alarmowego nie może zależeć od sprawnego działania Internetu. BLYNK stanowi tutaj jedynie nakładkę - taki wirtualny wyświetlacz i wirtualne przyciski sterujące - i nie ma on prawa zakłócać podstawowych funkcji układu. W takich przypadkach należy stosować inne procedury sterowania BLYNKiem nie wstrzymujące pracy pozostałych fragmentów kodu.
Skąd nasza aplikacja ma się dowiedzieć, że utraciła połączenie z serwerem i trzeba przestawić się pracę autonomiczną? Rozwiązań jest kilka. Najłatwiej wykorzystać istniejącą procedurę BLYNKa. Wywołanie procedury blynk.connected() zwraca 0 gdy brak jest połączenia. Możemy cyklicznie zapisywać na serwerze przypadkową liczbę i ją natychmiast odczytać. Porównując obie damy wiemy natychmiast czy połączenia działa czy nie (obie procedury wykonują się sekwencyjnie najpierw zapis potem odczyt). Możemy to samo zrobić pętlą zwrotną z wykorzystaniem widgetu EVENTOR w którym odbiór jednego wirtualnego pinu generuje wysłanie innego. To tylko przykładowe rozwiązania - BLYNK daje nam tu nieograniczone możliwości na swoje własne pomysły
Innym rozwiązaniem jest zastosowanie dwu mikroprocesorów - jednego odpowiedzialnego za działanie systemu sterowania i drugiego dedykowanego jedynie do połączenia z serwerem BLYNK. Fizyczne rozdzielenie procesów daje pełną gwarancję odseparowania od siebie obu części programu - naszej głównej aplikacji i odpowiedzialnego za komunikację BLYNKa. Dodatkowa zaleta to wzajemna kontrola poprawności pracy obu procesorów. Od pewnego czasu ten drugi sposób jest mocno preferowany w moich projektach.
Sprawa jest na tyle poważna, że poświecę jej osobny wpis.
Działający w naszym module program potrzebuje czasami informacji o tym czy aplikacja mobilna jest w danym momencie włączona (online). Może to być przydatne np. gdy chcemy wysyłać dane do telefonu jedynie w sytuacji aktywnego korzystania z aplikacji BLYNK. Takie rozwiązanie znakomicie ogranicza nam ruch w sieci co może mieć istotne znaczenie przy dostępie do internetu poprzez GPRS. BLYNK umożliwia przesłanie informacji o otwarciu/zamknięciu APP do mikroprocesora. Szczegóły tutaj >>>
Wszelkie informacje o tym czy aplikacja i moduły są online dostępne są oczywiście w serwerze BLYNK. Ale ideą tego systemu jest by serwer był praktycznie niewidoczny dla użytkownika. Toteż sposoby pobierania różnych pożytecznych informacji wprost z serwera zostaną omówione przy innej okazji.
Za chwilę - co można zrobić by zwiększyć pewność dotarcia do odbiorcy informacji w systemie BLYNK.
/Wykorzystano zdjęcia z portali rp.pl/
8
Brak komentarzy:
Prześlij komentarz