BLYNK – kontrola dostarczania przesyłek cz. II – aplikacja

By: | Post date: Wrzesień 14, 2017

Podobny obraz

Oparcie kontroli przepływu danych pomiędzy aplikacją i urządzeniem na standardowych, zaimplementowanych w BLYNKu mechanizmach może być daleko niewystarczające. Dotyczy to szczególnie systemów zdalnego sterowania gdzie użytkownik nie widzi skutków wydawanych telefonem poleceń (a dla takich celów został przecież stworzony BLYNK).

Można temu zaradzić wprowadzając swoje własne metody śledzenia przesyłek  odpowiednio konfigurując aplikację mobilną i dopisując w kodzie programu  procedury kontroli transmisji. Oto kilka takich propozycji 

Mam kilka własnych patentów na szybką ocenę właściwego działania komunikacji w projekcie

Dla aplikacji mobilnej stosuję:

  1. sygnalizację prawidłowej łączności urządzenie – aplikacja (czy urządzenia się „widzą”)
  2. zwrotne potwierdzenie wykonania komendy wysłanej z aplikacji mobilnej (potwierdzenie odbioru) – tylko w przypadku bardzo istotnych sygnałów

W module mikroprocesorowym dodaję

  1. LED sygnalizujący poprawną pracę urządzenia
  2. LED sygnalizujący brak połączenia z serwerem

Dziś o tym co i jak można pokazać w aplikacji w telefonie by być pewnym prawidłowego funkcjonowania komunikacji w naszym projekcie.

Ad.1 Cykliczna sygnalizacja prawidłowej łączności urządzenie – aplikacja

We wszystkich projektach dodaję do aplikacji mobilnej wirtualnego LEDa, sterowanego cyklicznie – najczęściej co 1 sekundę –  z mikroprocesora. Po włączeniu aplikacji w telefonie mam natychmiastowy i wyraźny sygnał czy komunikacja w systemie przebiega prawidłowo. To rozwiązanie teoretycznie duplikuje funkcje HEARTBEAT ale jest dużo bardziej czytelne i niezawodne.  W poniższym przykładzie pin V0 dołączony do wirtualnego LEDa w aplikacji zmienia swój stan co 1 sekundę.

A tu symulacja zerwania połączenia pomiędzy APP i serwerem i ponowne jego zestawienie.

Przerwanie komunikacji (wyłączenie lokalnego serwera BLYNK) natychmiast (max opóźnienie 1 sek) wstrzymuje miganie LEDa. To bardzo najszybsza informacja braku połączenia pomiędzy mikroprocesorem a APP. Oczywiście nie odświeża się wtedy odczyt temperatury. Ale niebieski przycisk działa jakgdyby wszystko było OK. Oczywiście nie wywołuje to żadnej reakcji w układzie – tutaj brak komunikatów na porcie szeregowym. Jeśli nie mamy dostępu do urządzenia to bez kontrolnego tego LEDa nie można jednoznacznie stwierdzić, iż coś w układzie szwankuje.

Po przywróceniu połączenia (ponowne uruchomienie serwera)  aplikacja potrzebuje czasu by zacząć prawidłowo działać. Czas synchronizacji  APP w systemie jest różny – od kilku do kilkudziesięciu sekund. Miganie wirtualnego LEDa jednoznacznie wskazuje na poprawną pracę układu. Niebieski przycisk zachowuje się bez zmian ale powoduje w module wysłanie komunikatu „BUTTONON/OFF” na port szeregowy.

W bardziej złożonych systemach gdzie istnieje możliwość uszkodzenia komunikacji niezależnie w jednym lub drugim kierunku (np. przy połączeniu Arduino NANO z ESP8266 portem szeregowym) takie kontrolne piny wirtualne wysyłam w obu kierunkach. Pozwalają na błyskawiczną ocenę działania projektu a w razie awarii bardzo ułatwiają diagnozę i naprawę. Naprawdę warto to stosować.

Ad.2 Sterowanie z potwierdzeniem odbioru.

Powyższy przykład  ujawnił jeszcze jeden problem – nawet w przypadku właściwej komunikacji w systemie wciąż nie jesteśmy pewni czy nasz rozkaz został wykonany. Naciskając niebieski przycisk musimy przyjąć na wiarę, że po drugiej stronie połączenia moduł zadziałał tak jak tego oczekujemy. To cecha tzw. otwartych systemów sterowania gdzie sygnał sterujący biegnie tylko w jednym kierunku. By pozbyć się tej niepewności należy wprowadzić sprzężenie zwrotne w postaci sygnału potwierdzającego wykonanie polecenia.

Kiedyś to była wyższa szkoła jazdy w automatyce dziś ten system  dzięki rozwojowi elektroniki mocno spowszechniał i często nawet nie jest dostrzegany. A właśnie z taką sytuacją mamy do czynienia gdy komórka czy tablet dźwiękiem lub wibracją potwierdza naciśnięcie wirtualnej klawiatury, gdy LED w telewizorze zapala się na zielono po naciśnięciu klawisza ON  lub gdy samochód miga do nas przyjaźnie po naciśnięciu pilota. To są właśnie sprzężenia zwrotne informujące nas, że nasz rozkaz dotarł do urządzenia, został zrozumiany i wykonany.

Również w projektach z  BLYNKiem  chcemy mieć możliwość potwierdzeń szczególnie dla ważnych  sygnałów – zamknięcia bramy garażu, uzbrojenia alarmu czy zdalnego wyłączenia żelazka. Tu musimy mieć pewność dotarcia a nawet wykonania polecenia i tą informację chcemy mieć pokazaną na ekranie aplikacji. Tej funkcjonalności nie ma w standardzie BLYNKa ale możemy ją z łatwością zaimplementować sami.

Fizyczna realizacja sprzężenia zwrotnego nie jest tak oczywista jak mogłoby się wydawać. Problemem jest wybór miejsca w systemie, z którego pobieramy sygnał zwrotny o wykonaniu wysłanej przez nas komendy. I tak przy sterowaniu piecem CO najłatwiej wysłać sygnał zwrotny z modułu załączającego grzanie – sygnał zwrotny otrzymamy natychmiast. Ale to wcale nie oznacza, że piec się załączył (przełącznik pieca może być w pozycji WYŁ). Lepiej umieścić czujnik temperatury na rurze CO. Dostaniemy pewną informację o załączeniu/wyłączeniu pieca już po kilku – kilkunastu sekundach, co nie oznacza, że ogrzewamy pomieszczenia (termostat może być w pozycji 0). Czujnik temperatury w pokoju jednoznacznie wskaże czy system działa i dodatkowo pozwoli na jego automatyczne wyłączenie po uzyskaniu żądanej temperatury ale czas na uzyskanie potwierdzenia wydłuży się do kilku-kilkunastu minut. Optymalizacja punktu sygnału zwrotnego to ważne i ciekawe zagadnienie układów automatyki.

W większości przypadków wystarczy potwierdzenia wysłane z modułu sterującego o odebraniu komendy – ale uwaga np.dla bramy garażowej budowa sterowania bez czujnika otwarcia/zamknięcia oraz czujnika obecności osób w zasięgu bramy to gwarancja poważnych kłopotów.

Poniżej przykład implementacji sterowania wirtualnym klawiszem z potwierdzeniem odbioru.

Potwierdzeniem odebrania sygnału zmiany stanu klawisza z OFF na ON jest zmiana koloru zielonego na czerwony. Gdy brak jest komunikacji w systemie kolor klawisza pozostaje nie zmieniony (zielony).

Ten sposób daje w 99,9% pewności poprawnego działania urządzenia. O pozostałym 0,01%  – przy innej okazji.

W przykładach użyłem płytki testowej z modułem D1 MINI

Kod programu do testowania połączeń tu >>>> i obsługi czujnika DS18b20

Zdjęcia zaczerpnięte z serwisu www.istockphoto.com

9

Dodaj komentarz

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