BLYNK blokuje program przy braku połączenia – co zrobić? cz. I

By: | Post date: Wrzesień 24, 2017

BLYNK to Internet a z internetem bywa różnie.

Najgorzej przerwy w łączności znosi mikroprocesor. Wiadomo już jak można sprawdzić brak połączenia w systemie BLYNK. Jednak to że WIEMY nie naprawi nam łącza choć biblioteka BLYNKa będzie wciąż i wciąż próbować zestawić połączenie. I to wciąż i wciąż mimo, iż bardzo pożądane w standardowych aplikacjach może być przyczyną sporych kłopotów w niektórych projektach. W takich gdzie główne funkcje programu muszą działać bez zakłóceń niezależnie od istnienia internetowego połączenia – ot choćby w systemie sterowania temperaturą w mieszkaniu. Nie do przyjęcia jest przenikliwe zimno (albo tropikalny upał) tylko dlatego, że popsuł się domowy router a nasz sterownik zawiesił się w nieustalonym bliżej stanie.

Kolejne odcinki będą o tym co robić by BLYNK nie blokował programu przy braku połączenia z serwerem.

Jeszcze raz popatrzmy jaki jest efekt braku lub utraty połączenia z serwerem od strony mikroprocesora. Przykładem będzie omawiany już moduł D1 MNINI z ESP8266 czyli Internet via WiFi.

Tym razem ważny jest nie ekran aplikacji ale wydruki na monitorze szeregowym mikroprocesora na COM9. Na starcie biblioteka BLYNK próbuje połączyć się z siecią WiFi wpisaną w kodzie programu ( ssid[] i pass[). Jak widać z sukcesem nastąpiło przyłączenie do sieci ty0 a modułowi został nadany adres 192.168.2.184. Kolejny krok to próba połączenia się s serwerem BLYNK – w tym przykładzie to serwer lokalny zainstalowany pod adresem 192.168.2.19. BLYNK drukuje piękne logo i ….. dostaje czkawki. Wiesza się a w zasadzie wciąż ponawia próbę połączenia z serwerem pozostając na stałe w procedurze  Blynk.begin(auth, ssid, pass, IPAddress(192, 168, 2, 19)). I jeśli połączenie z serwerem nie zostanie przywrócone stan taki będzie trwał i trwał. A w opisie podano że powinien próbować jedynie przez 30 sek. U mnie zawiesił się na stałe.

Załóżmy, że jakimś sposobem przywróciliśmy połączenie z serwerem (w przykładzie serwer został uruchomiony). Program wskakuje w normalny cykl pracy tj. co sekundę drukuje pomierzoną czujnikiem DS18b20 temperaturę i reaguje na przyciski w aplikacji telefonu. I tak powinno być po wsze czasy i o jeden dzień dłużej.

Ale złośliwość rzeczy martwych nie zna granic. Po chwili ponownie zrywa się połączenie z serwerem (wyłączam serwer) i program znowu dostaje czkawki. Trochę mniej dokuczliwej, gdyż co 7-8 sek pozwala programowi głównemu na przejęcie kontroli nad programem i na wydruk temperatury ale trudno to nazwać normalną pracą. Tu hamulcowym jest procedura Blynk.run() mająca w sobie również funkcje odtwarzania połączenia z serwerem po jego zaniku. Oczywiście po ponownym włączeniu serwera BLYNK wszystko wraca do normy. Jak dla mnie – NIE DO PRZYJĘCIA!

Informacja o uszkodzeniu

Takie zachowanie biblioteki BLYNKa to dowód, iż jego twórcy to raczej programiści niż elektronicy. Nie ujmując nim niczego ze znajomości mikroprocesorów tego typu kwiatki są charakterystyczne dla osób nie obcujących na co dzień z żywą materią (elektroniką praktyczną). I niestety problem nie jest zadowalająco rozwiązany do dziś – mamy tylko łaty zmniejszające uciążliwość takiego działania BLYNKa.

Ale zacznijmy od początku. Pożądanym stanem pracy systemu jest taki, w którym istnieje prawidłowa komunikacja. A jeśli cokolwiek szwankuje musimy o tym szybko i wyraźnie zostać powiadomieni. Ja w tym celu instaluję w każdym projekcie specjalnego LEDa odpowiedzialnego tylko za informowanie o stanie połączenia z serwerem (lub korzystam z istniejącego LEDa na module procesora). Doświadczalnie ustaliłem, że najbardziej czytelnym sygnałem awarii jest zaświecenie się czerwonego lub niebieskiego LEDa. Wtedy nie pozostaje nic innego jak zakasać rękawy i poszukać gdzie ginie sygnał między modułem a serwerem.

By zgłosić problem program musi mieć informację o braku połączenia. Bibloteka BLYNK ma zaszytą w sobie procedurę kontroli połączenia – Blynk.connected(). Procedura zwraca 1 gdy jest OK i 0 gdy brak połączenia z serwerem z jakiegokolwiek powodu. Informacją tą steruję wspomnianego wyżej LEDa. Co 1 sek wywoływana jest procedura

void testconnect()
{
if (Blynk.connected()) {
digitalWrite(led_blue, HIGH); //wskaźnik łączności z serwerem stan wysoki- wyłączenie LEDa
} else {
digitalWrite(led_blue, LOW);
}
}

Wiemy już, że nie mamy połączenia z serwerem – co zrobić z tą wiedzą – w następnym odcinku

Zdjęcia zaczerpnięte z serwisu pixabay.com

11

Dodaj komentarz

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