BLYNK – kontrola dostarczenia przesyłek cz. I

By: | Post date: Wrzesień 12, 2017

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)

efekt będzie jednaki –  kręcące się bez końca kulki na ekranie telefonu. Po naprawie połączenia wszystko wraca do normy ale … gdy utracimy połączenie z serwerem w trakcie korzystania z aplikacji nic nas nie poinformuje o tym fakcie – aplikacja zachowuje się na pierwszy rzut oka nadal poprawnie.

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

Dodaj komentarz

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