Widget API WEBHOOK – Serwer lokalny i cloud serwer razem

By: | Post date: Styczeń 27, 2018

BLYNK funkcjonuje w dwóch odrębnych światach. W internetowej chmurze zainstalowane są serwery publiczne. Dostępne dla każdego z dowolnego miejsca na świecie ale …. płatne są niestety. Możemy serwer BLYNK także zainstalować w sieci prywatnej – jest szybki, bezpieczny i co najważniejsze całkowicie darmowy. Ale ma kilka ograniczeń, w tym spory problem z udostępnieniem swoich zasobów na zewnątrz w sposób bezpieczny dla przeciętnego użytkownika Internetu. Przez cały okres rozwoju projekt BLYNK te dwa światy trzymane są na spory dystans. To zrozumiałe biorąc pod uwagę komercyjny charakter projektu. Ale BLYNK to jest BLYNK. Ma niesamowite możliwości. W tym, na przykład, jak ominąć swoje własne ograniczenia. Dziś próba połączenia dwu światów i co z tego wyniknie. Czyli jak prosto zburzyć berliński mur.

Ten blog poświęcony jest jedynie słusznej – darmowej – wersji BLYNKa. Większość więc informacji powiązana jest z lokalnym serwerem systemu. Dziś jednak głównym bohaterem będzie Cloud Server – publiczny, komercyjny serwer BLYNKa. Ukryty za domeną blynk-cloud.com  zachęca do przyłączania możliwościami niedostępnymi (lub trudno dostępnymi) w lokalnej wersji. Do najważniejszych z nich należą

  • nieograniczony dostęp z każdego miejsca
  • bieżąca aktualizacja
  • możliwość wysyłania emaili i notyfikacji
  • kilka inny drobiazgów, na razie nie istotnych

Ale za to i jeszcze za kilka innych udogodnień trzeba zapłacić. Czy warto? To już każdy musi zdecydować sam.

Ale można pokombinować inaczej. Można pozostawić cały system pod zarządem lokalnego serwera a do serwera publicznego przenieść jedynie wybrane widgety, do których potrzebny jest globalny dostęp. A wszystko to bez naruszania bezpieczeństwa lokalnej sieci i bez otwierania BLYNKowych portów lokalnego serwera na świat.

Jak to zrobić? W pierwszym rzędzie należy zapomnieć iż serwer lokalny i Cloud Serwer to bracia syjamscy. Należy potraktować serwer publiczny jak zupełnie obcy zewnętrzny system, który zamierza się przyłączyć do lokalnego BLYNKa.

Po drugie wykorzystać omówione w poprzednim wpisie istniejące w BLYNKu możliwości zewnętrznego sterowania z wykorzystaniem HTTP/S API.

Po trzecie – skorzystać z ogromnego ułatwienia jakim jest widget WEBHOOK podczas pracy z procedurami API.

Te trzy elementy gwarantują sukces i pozwalają rozwiązać dylemat z ciastkiem – jak używać w sterowaniu systemem w pełni bezpiecznej lokalnej wersji serwera a jednocześnie (równolegle) korzystać z ogólnie dostępnego publicznego serwera.

W tej konfiguracji podstawowym sercem systemu jest serwer lokalny. To z nim, w ramach sieci LAN, połączone są mikrokontrolery i aplikacje na telefonach i tabletach. W aplikacjach, bez żadnych ograniczeń, należy zainstalować wszystkie potrzebne widgety nie zważając na ich liczbę i cenę. Warto więc umieścić w aplikacji wszelakie elementy konfiguracyjne, testujące i monitorujące pracę projektu. Tu też umieszcza się sterowania, które w żadnym przypadku nie powinny być wyprowadzane na zewnątrz (np. dezaktywacja alarmu). Jednym słowem wszystko na co przyjdzie ochota.

Na serwerze publicznym należy założyć dowolne konto oczywiście nie związane z żadnym konkretnym modułem mikroprocesorowym. Będzie to tylko ekran widgetów będących swoistym przedłużeniem pinów z serwera lokalnego. Instalować należy jedynie najważniejsze widgety, do których dostęp jest pożądany z dowolnego miejsca na świecie. Zazwyczaj nie jest tych elementów dużo i większość projektów uda się zmieścić w darmowym limicie 2000 pkt.

I najważniejsze – przy pomocy widgetów WebHook należy połączyć konkretne piny serwera lokalnego z wybranymi widgetami (pinami) w aplikacji serwera publicznego. Ilość elementów WebHook będzie odpowiadać ilości wyprowadzonych na zewnątrz zmiennych.

Widget WEBHOOK – co to takiego?

Widget WEBHOOK jest dziwnym widgetem gdyż jako jedyny pozwala się przypisać do wcześniej dowiązanych pinów. To przypisanie daje możliwość „wystawienia” zawartości tego pinu na zewnątrz lub zapisania zewnętrznej danej do pinu poprzez procedury HTTP/S API. Jednocześnie WEBHOOK robi za translator całego złożonego protokołu (nagłówka) API niezbędnego do prawidłowej komunikacji z systemami zewnętrznymi. Przy wysyłaniu danych obudowuje je właściwym kształtem nagłówka, zaś przy odbiorze odziera odebraną informację z nagłówka przesyłając do systemu „czystą” daną. Mówiąc widget „coś robi” trzeba wiedzieć, iż wszystkie te procesy odbywają się w serwerze BLYNK  a widget je jedynie inicjuje.

Działanie Webhook jest zbliżone go widgetu EVENTOR. Każda zmian wartości pinu powiązanego z WebHook-iem aktywuje go tzn. wykonywana jest w tym momencie procedura wysłania żądania API zapisanego w ustawieniach widgetu. Również każde wywołanie procedury zapisu wartości do pinu (BLYNK.virtualwrite()) uruchamia działanie widgetu.

Najważniejsza jest więc konfiguracja widgetu w ustawieniach setup. Od właściwego  wypełnienia poszczególnych pól zależy prawidłowa praca protokołu API i komunikacji między serwerami.

 

Pole PIN musi odpowiadać pinowi na serwerze lokalnym, z którego lub do którego będzie przesyłana dana z serwera publicznego.

Nr pinu serwera publicznego łączonego z pinem PIN znajduje się treści URL w kolejnym polu. Pole to należy wypełnić właściwym adresem URL odpowiadającym wybranej komendzie API (patrz poprzedni wpis) np.

http://blynk-cloud.com/AUTH/get/Vx

Tym sposobem stworzone zostało połączenie pomiędzy pinem wybranym w polu PIN a pinem Vx serwera publicznego. Komenda /get/ informuje, iż dane będą pobierane z Vx do V/PIN/.

Wybór pola GET jest więc w tym przypadku oczywiste.

Ople CONTENT TYPE ma dwie opcje json i text. Ich wybór zależy od sposobu obsługi API przez urządzenie zewnętrzne. Dla serwera BLYNK można wybrać oba – tu wybrany został json.

Ostatnie okno  to pole BODY, w którym można wpisać dodatkowe treści przesyłanej informacji. Pole to zostanie dokładniej opisane przy innej okazji.

A teraz przyklady

Wysyłanie danej z serwera lokalnego do serwera publicznego

 

Połączenie pinu V10 serwera lokalnego z pinem V1 serwera publicznego dla wysłania informacji uzyskuje się wpisaniem następującego adresu URL

http://blynk-cloud.com/AUTH/update/V1?value=/pin/

Polecenie UPDATE to metoda  GET, której efektem jest wysłanie zawartości zmiennej V10. Oznaczenie /pin/ na końcu adresu oznacza, iż wartość V10 (znajdująca się w polu PIN) zostanie wysłana do pinu V1 serwera publicznego.

Jeśli do V10 dołączony jest SLIDER to zmiana jego nastawy zostanie niezwłocznie przesłana do pinu V1 i jeśli jest to np. wyświetlacz to zostanie tam wyświetlona.

Proste? Bardzo!!!

Trochę trudniej jest odbierać informacje z zewnątrz. Z dwu powodów. Zmiana stanu widgeta (zawartości vpin) w serwerze publicznym nie jest samoistnie wysyłana do serwera lokalnego. To oczywiste – serwer lokalny nie jest widziany spoza NAT. To widget WebHook musi zainicjować transmisje i to on musi odczytać aktualny stan widgeta na serwerze publicznym. Czyli co jakiś czas trzeba aktywować odpowiedni WebHook. ale by nie przegapić tej zmiany WebHook musi być aktywowany stosunkowo często np. co 1 sek.

Drugi problem to odbiór danej z zewnętrznego systemu i zapisanie jej pina serwera lokalnego. Ten sam pin służy do aktywowania widgetu WebHook i w tym samym widgecie będzie zapisana odebrana dana. By jednocześnie pogodzić obie funkcje trzeba zastosować pewien trick. Ale po kolei.

W poniższym przykładzie  pin V11 serwera lokalnego połączony został z pinem V2 serwera publicznego. Dla wysyłki danych z V2 do V11 – a dokladniej dla wysłania żądania o wysyłkę danej z V2 do V11 – zastosowano widget WebHook, w którego w polu URL trzeba  wpisać

http://blynk-cloud.com/AUTH/get/V2

 

 

Trzeba jeszcze uruchomić cykliczne aktywowanie widgetu WebHook i spowodować odczyt pinu V11 w programie mikrokontrolera. W tym celu w kodzie procesora należy umieścić dwie procedury. Pierwsza to:

Blynk.virtualWrite(V11, value); gdzie value jest dowolną wartością np 1

Zapis value do pinu V11 spowoduje uruchomienie widgetu WebHook i „odpytanie” serwera publicznego o aktualną wartość pinu V2. Procedurę Blynk.virtualWrite()  należy więc umieścić w cyklicznie wywoływanej procedurze procesora czyli w jakim timerze.

Efektem tego będzie zapisanie nowej wartości z pinu V2 do pinu V11. Do odczytania nowej wartości V11 należy zastosować standardową procedurę BLYNK_WRITE()

BLYNK_WRITE(V11){
  String webhookdata = param.asStr();
  Serial.println(webhookdata); 
  Blynk.virtualWrite(V12, webhookdata);
}

W zmiennej webhookdata zostanie umieszczona aktualna wartość pinu V2. Ale dla wyświetlenia jej w aplikacji trzeba użyć innego numeru pinu – tu V12. Dlaczego? Za prawidłową odpowiedź nagroda niespodzianka.

Jeszcze tylko jeden siurprize – odebrane z serwera publicznego dane mają trochę dziwny format

[„dana”]

czemu? pewnie ktoś wie – widać tak już urok komunikacji HTTP/S API. Ale to żaden kłopot by z tego łańcucha wydobyć potrzebną  informację.

I to wszystko. Proste? Jakby mniej ale do ogarnięcia.

Najważniejsze, iż cała komunikację i obróbkę danych bierze na siebie w obu przypadkach widget WebHook.

A tak to wygląda w praktyce:

32

Dodaj komentarz

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

Translate »