BLYNK sterowany z zewnątrz systemu – HTTP API i WEBHOOK cz. 1

By: | Post date: Styczeń 22, 2018

BLYNK może wydawać się kompletnym, spójnym i zamkniętym systemem przeznaczonym do zastosowań w ramach SMART HOME czy IoT. Może ale nie jest. Jest jedynie fragmentem większej całości, której podstawowym trzonem jest znane i lubiane ARDUINO. Ale BLYNK coraz śmielej przekracza granice określone przez moduły i shieldy typu UNO NANO czy LEONARDO głownie dzięki oszałamiającej karierze ESP8266. Wychodzi nawet poza własne, wcześniej określone granice pozwalając na integrację blynkowego systemu z dowolnymi środowiskami sterowania i zarządzania automatyką. To już nie jest nawet rewolucja – to może wyglądać na podcinanie własnej gałęzi poprzez dopuszczenie do wykorzystania BLYNKa przez mniej dopracowane aplikacje. Ale to tylko pozór. Ta zadziwiająca polityka otwarcia na świat konkurencji tak odwrotna w stosunku do profesjonalnych systemu typu Z-wave ma swoje uzasadnienie. BLYNK jest po prostu świetny i konkurencja nie jest w stanie przejąć zagospodarowanego przezeń obszaru. A że ktoś lubiący Domoticza czy OpenHuba wykorzysta fragment BLYNKa – to tym lepiej. Jest duża szansa, że poznawszy system dokładniej, zmieni swoje preferencje. W tym kontekście szerokie możliwości integracji BLYNKa z zewnętrznymi środowiskami przestają dziwić.

HTTP/S API i WEBHOK to dwa mechanizmy zaszyte na trwale w programie BLYNK pozwalające na pełną integrację systemu z obcymi środowiskami informatycznymi. Celowo wskazane są tu środowiska informatyczne a nie automatyki i sterowania. Oba te mechanizmy są bowiem charakterystyczne dla zastosowań informatycznych np w internetowych sklepach czy programach zarządzania bazami danych. Tak więc BLYNK integruje się na wysokim poziomie abstrakcji ale wykorzystuje do tego najprostsze, najbardziej przyjazne i powszechne dostępne  narzędzia. Tym narzędziem jest Internetowa przeglądarka i powiązane z nią protokoły HTTP/S i programistyczne środowisko API. Wielokrotnie zgłaszany błąd przeglądarki internetowej 404 jest właśnie efektem działania API.

BLYNK.pl nie jest miejscem by szerzej omawiać te zagadnienia. Na potrzeby tego wpisu wystarczy informacja, iż istnieje prosty sposób wysyłania i odbioru żądań dostarczenia określonej informacji oparty na identycznym mechanizmie jak przy pobieraniu stron przez internetową przeglądarkę. Odpowiedzią na żądanie (zapytanie), które ma postać bardzo zbliżoną do typowego internetowego adresu URL, nie jest strona internetowego portalu ale jakieś konkretne dane. Format tych danych może być praktycznie dowolny, podobnie jak i ich rozmiar.

Implementacja HTTP/S API w systemie BLYNK oznacza, iż jest on przygotowany na odbiór żądań i potrafi to żądania w prawidłowy sposób obsłużyć tzn. wysłać dane do nadawcy polecenia. Rozkaz wysłania danych ma postać typowego wywołania HTTP/S. Na przykład odczytanie informacji z serwera np o tym czy aplikacja w telefonie jest aktywna dokonuje się poleceniem

http://blynk-cloud.com/6ca9f32xxxxxxxxxxxxxxxx0c82deb/isAppConnected

a odebrany wynik a postać

Zachowanie w sekrecie wartości kodu AUTH jest absolutnie niezbędne. Jak to zostanie niebawem pokazane dostęp do tego kodu pozwala na przejęcie całkowitej kontroli nad danym projektem systemu BLYNK.

W ramach poleceń API przesyłanych jest znacznie więcej informacji, których wynikiem jest wyświetlenie komunikatu true/false. By to zobaczyć najlepiej użyć Firefoxa udostępniającej zakładkę wyświetlającą treści nagłówków wysyłanej i odbieranej  informacji w ramach API.

Gdyby chcieć w programie mikrokontrolera wysłać i odebrać takie polecenie API trzeba przygotować się na obróbkę danych o długości kilkuset a nawet kilku tysięcy znaków. A tu już pojawia się problem z dostępnością pamięci w typowym mikroprocesorze. Na szczęście widget WEBHOOK „oczyszcza” odebrane dane z niepotrzebnych informacji przeyłając w systemie BLYNK jedynie istotne wielkości.

Powyższe żądanie wysłane jest do serwera publicznego BLYNKa. Dla serwera lokalnego może być konieczność wskazania portu na jakim serwer nasłuchuje poleceń API. Domyślnie jest to port :8080 . Polecenie odczytania stanu aplikacji w telefonie będzie wyglądać jakoś tak

http://192.168.2.19:8080/f845be3b89e74d28b164bd8a9c1d38ba/isAppConnected

W tym przypadku ochrona kodu AUTH jest zbędna – nie ma możliwości dostania się do serwera z zewnątrz o ile tylko nie są otwarte na świat porty BLYNKa na domowym routerze.

Prawdziwe możliwości HTTP API uwidoczniają się po zastosowaniu komend GET i PUT

Odczytywanie wartości pinów – rzeczywistych i wirtualnych

Wszystkie dane w ramach komunikacji API są wysyłane i pobierane z serwera. To czy efekty tych działań zostaną uwidocznione w telefonicznej aplikacji lub/i w programie mikrokontrolera zależy już tylko od właściwego przyporządkowania pinów do widgetów i ich prawidłowej obsługi w programie. Ale zarówno aplikacja jak i mikrokontroler nie są wstanie stwierdzić czy zachodzące w systemie zmiany spowodowane są wewnętrznymi sterowaniami czy też pochodzą spoza systemu BLYNK. Taka „wiedza istnieje” jedynie w serwerze.

Do odczytania stanu widgeta przez przeglądarkę – a tak naprawdę wartości powiązanego z nim pinu rzeczywistego lub wirtualnego – należy użyć funkcji GET

Poniżej przykład i efekt jej zastosowania dla dwu widgetów BUTTON i SLIDER

Widget BUTTON przyłączony jest do pinu V1 zaś SLIDER do V3.

Poleceniem pobierającym aktualną wartość pinu wirtualnego jest

http://192.168.2.19:8080/f845be3b89e74d28b164bd8a9c1d38ba/get/V1   lub V3

a efekt działania wygląda mniej więcej tak

Zapis danych do pinów rzeczywistych i wirtualnych

Jeszcze ciekawsze efekty można uzyskać wysyłając poprzez API dane do serwera na konkretny nr pinu. Zrobić to można na dwa sposoby – albo komendą PUT albo tą samą komendą GET oznaczoną jako UPDATE. Komenda PUT wymaga jednak wysłania dodatkowego pola danych a tego nie można zrobić z paska adresu przeglądarki. Zapis danych do pinów pokazany więc będzie na przykładzie komendy GET (UPDATE)*.

*Uwaga: Nie wszystkie systemy wspierające API mają zaimplementowaną tą funkcję. BLYNK  ma.

http://192.168.2.19:8080/f845be3b89e74d28b164bd8a9c1d38ba/update/V0?value=0

a skutek działania polecenia wygląda tak

Całość zagadnienia opisana jest tu  >>>>> i tu >>>>>>>> łącznie z przykładami stosowania tych poleceń.

Jak można wyczytać z powyższych opisów protokół API umożliwia w systemie BLYNK znaczne więcej.

Oprócz opisywanego wcześniej badania stanu aplikacji w telefonie identyczną procedurę można zastosować w odniesieniu do mikrokontrolera poleceniem

http://IPadr/AUTH/isHardwareConnected

Ważną funkcją również udostępnioną w ramach API jest możliwość zmiany parametrów widgetów – analogicznie do działania funkcji

Blynk.setProperty()

Generalna składnia tych komunikatów ma postać

http://IPadr/AUTH/update/Vx?color=%23FF00FF

gdzie Vx to numer pinu. Kod kolorów w BLYNKu w postaci #FF00FF został tu zastąpiony ciągiem %23FF00FF gdzie %23 jest kodem znaku #

Dla innych parametrów ciąg color  należy zastąpić właściwym poleceniem.

Można również zmusić  BLYNKa do wysyłana wiadomości w postaci notyfikacji

http://IPadr/auth_token/notify

{
  "body": "message no less than 255 chars."
}

i emaili

http://IPadr/auth_token/email

BODY
{
  "to": "email",
  "title": "title",
  "subj": "subj"
}

ale w obu przypadkach niezbędne będzie dodanie do polecenia API pola BODY zawierającego treść wysyłanych informacji.

Dla pinow, których wartości są zapisywane na serwerze można za pomocą API ściągnąć całą ich historię :

http://IPadr/auth_token/data/pin

W tym przypadku należy się liczyć z dużą ilością danych i należy to uwzględnić przy obsłudze tego polecenia.

Na koniec dostępne są dwa elementy opisujące cały projekt zapisany na serwerze BLYNK. Pierwsze to możliwość bezpośredniego pobrania kodu QR z zapisanymi w nim danymi o projekcie:

http://IPadr/auth_token/qr

oraz pełen spis ustawień i konfiguracji projektu dla danego kodu AUTH

http://IPadr/auth_token/project

To ostatnie polecenie może posłużyć jako swoisty backup projektów zapisanych na serwerze na wypadek np. utraty konta lub danych do logowania.

Wszystko to jest jedynie zarysem funkcjonalności jakie oferuje interface API HTTP/S w systemie BLYNK. Jego zastosowanie  nieprawdopodobnie poszerza możliwości integracji BLYNKa z praktycznie dowolnym systemem informatycznym. Ale to już zupełnie inna historia.

31

3 komentarze

Dodaj komentarz

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

Translate »