BLYNK - kontrola dostarczania przesyłek cz. III - moduł mikroprocesora

W elektronice dawnych wieków urządzenie i użytkownik byli połączeni w sposób bezpośredni. Użytkownik dowiadywał się o stanie urządzenia za pomocą zainstalowanych w nim wskaźników, mierników i wyświetlaczy. Urządzenie przyjmowało plecenia przyciskami, potencjometrami czasem klawiaturą podłączonymi bezpośrednio do niego. Nawet w tak zwanych systemach zdalnych gdzie wskaźniki i manipulatory były nieco oddalone od obiektu regulacji wszystko odbywało się zestawionymi na stałe kanałami łączności przewodowej lub radiowej. Można więc bez kozery uznać, że były to wewnętrzne połączenia urządzenia. Aby poznać co dzieje się z urządzeniem lub nim posterować należało podejść i zrobić to bezpośrednio w urządzeniu.
Sytuacja diametralnie zmieniła się wraz z erą Internetu. Użytkownik w większości procesów został fizycznie oddzielony od urządzeń. Tak drastycznie, iż może znajdować się na końcu świata i wciąż jest w stanie sterować urządzeniem identycznie jakby stał obok. Ale gdy łączność się urywa nie pozostaje nic innego jak pokornie podreptać do urządzenia by zbadać co dolega pacjentowi. Ten wpis będzie o diagnostyce komunikacji od strony modułów mikroprocesorowych.

Za pomocą BLYNKa  zdalnie możemy dowiedzieć się wszystkiego co dzieje się w module i otaczającym go środowisku. Stąd we współczesnych urządzeniach coraz mniej jest elementów komunikacji z użytkownikiem.  Parę LEDów, jakiś przycisk czasem uproszczony wyświetlacz. Reszty dowiemy się logując się zdalnie do systemu urządzenia np. poprzez przeglądarkę. Czasami jednak komunikacja zawodzi i trzeba szybko zdiagnozować przyczynę obserwując te szczątkowe elementy komunikacji - kolor LEDa, szybkość jego  migania, kilka liter lub cyfr na wyświetlaczu LCD. Najczęściej wystarcza reset urządzenia lub powrót do ustawień fabrycznych. Ale najczęstszą przyczyną są problemy z kanałem łączności. Z moich doświadczeń z BLYNKiem potwierdza się to, iż głównym powodem awarii systemu była awaria sieci. Stąd mój  nacisk by w ograniczonych zasobach instalowanych w module wskaźników zawsze umieszczać jeden odpowiedzialny za sygnalizowanie poprawności transmisji danych.
Oczywiście najważniejszą sprawą jest informacja, czy moduł "żyje" - czy elektronika jest sprawna a program się nie zawiesił. Najczęściej wystarczy do tego jakiś LED określający kolorami lub częstotliwością pulsowania bieżący stan. Rzadziej wyświetlacz LED lub LCD. Procedurę sterującą takim LEDem umieszczam w pętli głównej. Jeśli kolejne jej obiegi zmieniają stan LEDa można wnioskować że program działa. Najczęściej LED ten jest taktowany tą samą procedurą co kontrolny vLED w aplikacji.
Z sygnalizacją stanu połączenia jest równie prosto - połączenie jest lub go nie ma. Protokół TCP/IP załatwia resztę. W każdym więc projekcie umieszczam co najmniej jednego LEDa (lub korzystam z istniejącego wbudowanego do modułu). W czasie poprawnej pracy LED jest wygaszony. Cyklicznie (najczęściej co 1 sek) sprawdzam łączność z serwerem procedurą Blynk.connected(); . Jeśli procedura zwróci wartość zero włączam LEDa. To oczywisty, wręcz bijący po oczach sygnał wzywający by zobaczyć co złego dzieje się w projekcie.

Kwestę sprawdzania komunikacji modułu z serwerem można rozwiązać na wiele różnych sposobów niekoniecznie stosując procedurę Blynk.connected() Podam dwa przykładowe

• cyklicznie zapisywać na serwer BLYNK losową liczbę a następnie ją odczytywać . Identyczność obu liczb świadczy o poprawnej komunikacji
• wykorzystać widget EVENTOR do wysłania do modułu potwierdzenia zmiany stanu jakiegoś wirtualnego pinu

Ten drugi sposób opiszę dokładniej ukazuje bowiem ciekawe możliwości BLINKa. BLYNK daje nam nie tylko pełną swobodę w dowolnym oprogramowaniu modułu swoim programem ale również pozwala uruchamiać własne programy w aplikacji (a właściwie na serwerze). Nie są one zbyt złożone ale znakomicie uzupełniają swobodę programowania całego systemu.
Zaprogramujmy EVENTOR w taki sposób

V0 to wirtualny pin przyłączony do vLED w aplikacji mobilnej wskazujący na połączenie z modułem. Widget EVENTOR "zawraca" wartość pinu V0 z powrotem do modułu w postaci pinu V10. Zmianą wartości pinu V10 program steruje LEDem sygnalizującym popawność transmisji. I pętla testowania łączności w systemie dla obu kierunków się zamyka. Tylko UWAGA - projekt musi być uruchomiony w aplikacji (z trójkącika w kwadracik w prawym górnym rogu) co jest logiczne.
Sygnalizacja stanu komunikacji z modułem sprawdza się nieźle ale ważne jest by po przywróceniu łączności program wrócił ponownie do właściwego działania bez konieczności ingerencji użytkownika. Z tym biblioteka BLYNK radzi sobie nieźle. W głównej procedurze Blynk.run zaszyta jest skuteczna funkcja przywracania połączenia z serwerem jeśli on znowu jest w sieci dostępny Widać to ładnie na filmie gdzie moduł niemal natychmiast nawiązuje połączenie z serwerem po jego włączeniu. A aplikacja w telefonie potrzebuje znacznie więcej czasu.
Równie skutecznie funkcja Blynk.run odtwarza zestawienie połączenia WiFi jeśli przyczyną awarii była utrata łączności bezprzewodowej. Twa to znacznie dłużej - kilkanaście - kilkadziesiąt sekund od momentu dostępności rutera bezprzewodowego ale działa bardzo skutecznie.
Podsumowując można stwierdzić , iż dodanie LEDów informacyjnych o stanie pracy programu oraz o poprawności łączności z modułem pomaga w diagnostyce ale nie jest niezbędne dla prawidłowej pracy i obsługi urządzenia. Procedury BLYNKa świetnie sobie radzą z przywracaniem prawidłowego działania programu po naprawie łącza sieciowego. Jeśli nic nie zepsuliśmy we własnej części programu nie ma praktycznie żadnej potrzeby ingerowania w działanie modułu w przypadku problemów z siecią po np. poprzez wymuszony reset. Po naprawie łącza biblioteka BLYNKa automatycznie zadba o przywrócenie prawidłowej pracy całego systemu
To dobra wiadomość dla elektroników korzystających z BLYNKa w swoich projektach.
Układ testowy pozostaje identyczny jak w częci II program testowy tutaj
Wykorzystano zdjęcia z serwisu clipsartfree.net

13