BLYNK ma swój własny system adresowania przesyłek. Dość tajemniczy i pozostający poza całkowitą kontrolą użytkownika.
Dziś co nieco o AUTH TOKEN w BLYNKU.
Bez Internetu nie byłoby BLYNKa. To żadne wiekopomne odkrycie - ale stwierdzenie niosące spore konsekwencje dla każdego fana "usieciowionej" elektroniki. Korzystanie z dobrodziejstw Internetu w dzisiejszej dobie nie wymaga już praktycznie jakiejkolwiek znajomości "jak to działa" Większość aplikacji w naszych urządzeniach sama martwi się o to by prawidłowo skonfigurować, połączyć i obsłużyć komunikację w ramach internetu. Nie inaczej jest z BLYNKiem. Szczególnie jego odmiana "komercyjna" posiada całkowicie automatyczny mechanizm konfigurowania urządzeń i aplikacji w ramach systemu BLYNK. Użytkownik kupuje gotowe urządzenie, ściąga aplikację z Google Play lub App Store i wszystko potrafi się jakoś samo skonfigurować i uruchomić.
W wersji dla hobbystów jest już nieco trudniej. Jeśli korzystamy z publicznego serwera BLYNK adresowanie w ramach systemu musimy ustawić ręcznie. Za to właśnie odpowiedzialny jest nasz AUTH TOKEN. Jeszcze trudniej jest gdy przenosimy serwer BLYNKa do siebie. Tu oprócz adresowania za pomocą Auth Token musimy opanować prawidłowe adresowanie w ramach internetu czyli te wszystkie IP adrress, Mask, DNS itd. Ten obszar wiedzy trzeba nabyć już we własnym zakresie. My pomówimy o funkcjach AUTH TOKEN.
char auth[] = "YourAuthToken";Taką linię będziemy musieli umieścić w każdym nawet najprostszym programie mikroprocesora komunikującego się przez internet w ramach BLYNKa. W zasadzie linia będzie wyglądać raczej jakoś tak
char auth[] = "53e4da8793764b6197fc44a673ce4e21";Te 32 znaki to właśnie unikalny wewnętrzny adres BLYNKa naszego projektu pozwalający na właściwą wymianę danych pomiędzy aplikacją mobilną a mikrokontrolerem. Po cholerę aż 32 znaki gdy np. taki adres Internetowy (wersja IP 4) dla wszystkich obecnych stosowanych urządzeń na świecie ma też 32 ale bity! to znaczy 8 znaków!. Sądzę, że to nauczka z historii internetu gdzie nie przewidziano jego globalnego charakteru i zaprojektowano zbyt małą pulę adresową. Stąd te wszystkie utrudnienia z maskami, NATami i innymi wynalazkami pozwalającymi na działanie internetu mimo nieprawdopodobnej liczby jego użytkowników w stosunku do pierwotnych założeń. Jak widać chłopaki z BLYNKa myślą baaardzo perspektywicznie :).
Ale nie tylko. AUTH w takiej to postaci robi również za hasło dostępu do systemu. Genialne. Niech ktoś spróbuje złamać kod o takiej długości! Ale o sprawach bezpieczeństwa będzie osobny wpis.
Auth Token jest nadawany w momencie tworzenia nowego projektu w aplikacji mobilnej. Generowany jest w serwerze i wysyłany do aplikacji mobilnej i emailem do użytkownika. W trzech (lub więcej ale o tym za chwilę) miejscach musimy mieć ten sam kod - na serwerze, aplikacji mobilnej i w programie mikroprocesora by wszystko mogło się komunikować między sobą. Oczywiście wcześniej te trzy urządzenia muszą się "widzieć" w sieci Internet. By otrzymać kod na skrzynkę pocztową musimy przy rejestracji nowego użytkownika jako login podać jakiś nasz istniejący adres email. Login staje się wtedy jednocześnie naszym kontaktem. To takie drobne smaczki, których sporo odnajdziemy w całym systemie.
Przypisaniem kodów między serwerem a aplikacją nie musimy się martwić - to dzieje się z automatu. Co więcej - nie mamy żadnej możliwości ingerencji ani w to jaki kod wygeneruje serwer ani jak i gdzie klucz zostanie wpisany do aplikacji w telefonie. To część know-how teamu BLYNKa pozwalająca kontrolować cały system (coś jak kontrola DNS przez Amerykanów daje kontrolę nad całym Internetem). Możemy go w telefonie tylko odczytać w ustawieniach projektu (Project Settings > Devices > My Devices > "nasz moduł"). Widoczny jest jedynie fragment a naciśnięcie kodu powoduje jego skopiowanie do schowka. Można go też odczytać w panelu administratora jeśli mamy postawiony swój serwer lokalny. I oczywiście mamy go w skrzynce pocztowej
Jedynie co możemy zrobić z kodem to go wygenerować - nawet wielokrotnie dla tego samego projektu (Refresh) - lub skasować kasując projekt lub jego fragment. Kod AUTH jest unikalny i jeśli kasujemy projekt kasujemy kod bezpowrotnie. Nie ma się co przejmować kodami - to byty mocno ulotne. Ale musimy chronić kody działających projektów by nie dostały się w niepowołane ręce - to klucz w pełni otwierający dostęp do naszego systemu.
To co napisałem powyżej - iż kod związany jest z projektem - nie jest już od pewnego czasu prawdą. Od chwili wdrożenia w systemie BLYNK mutiprocesorowości - a po polsku - możliwości przyłączenia do jednego projektu wielu modułów z różnymi typami mikroprocesorów - kod AUTH stał się kodem identyfikującym nie projekt a konkretny moduł mikroprocesorowy przyłączony do danego projektu.
Wcześniej istniała możliwość połączenia wielu modułów w jednym projekcie. Pod jednym warunkiem, że będą to wszystko moduły z tym samym typem mikroprocesora (niemalże jak u Forda z kolorami jego samochodów). Wpisanie tego samego AUTH do każdego z modułów pozwalał na pełną komunikację z serwerem/ aplikacją każdego procesora
Ale wszystkie mikroprocesory odbierają te same informacje. Jeśli więc w aplikacji ustawimy sterowanie portem GPIO 4 to w każdym z przyłączonych modułów port będzie sterowany w tym samy czasie. Jeśli których mikroprocesor wyśle informację do telefonu nie będziemy w stanie ustalić, który z modułów jest jej nadawcą. Możemy rozdzielić sterowania za pomocą pinów wirtualnych. Przypisując każdemu z mikroprocesorów inne piny wirtualne możemy sterować wybiórczo wybranym modułem. A aplikacja odbierając VP potrafi zidentyfikować nadawcę. System działał i wciąż działa znakomicie ale bardzo ograniczał możliwość rozbudowy projektu w oparciu o różne platformy procesorowe. Łączenie różnych procesorów wymagało tworzenia różnych projektów i krosowania sygnałów między nimi widgetem BRIDGE. Sposób był kłopotliwy i praktycznie nie był używany.
Za namową społeczności twórcy BLYNKa wdrożyli więc nową funkcjonalność - możliwość łączenia w jednym projekcie dowolnych platform. Do ich oznakowania wykorzystano właśnie AUTH TOKEN. Dziś komunikacja w ramach jednego projektu jest rozdzielana indywidualnie na każdy z mikroprocesorów (lub grupę mikroprocesorów) posiadający swój AUTH TOKEN.
Serwer BLYNK i aplikacja mobilna mają wiedzę o wszystkich kodach AUTH (mikroprocesorach) przypisanych do projektu. Sam mikroprocesor ma wpisany jedynie swój własny kod i nie pojęcia o istnieniu innych modułów w tym samym projekcie.
A co zrobić gdy chcemy przenieść jakąś informację z jednego modułu do drugiego? Np. przyciskiem w jednym mikroprocesorze zapalić LEDa na porcie drugiego? Tu rozwiązań jest kilka - jak to w BLYNKu. Możemy przesłać sterowanie poprzez widget EVENTOR, możemy użyć widgetu i funkcji BRIDGE możemy przesłać informacje poprzez serwer i widget WebHook i pewnie można zrobić to na kilka innych sposobów. Oj lubię tego BLYNKa.
Możemy więc mieć w BLYNKu wiele modułów przyłączonych do tego samego projektu. A co gdy chcemy mieć ten sam projekt na wielu telefonach? Z tym jest jeszcze mniejszy kłopot pomimo braku możliwości gmerania w kodzie AUTH w aplikacji. Na każdym urządzeniu musimy tylko zainstalować aplikację BLYNK i zalogować się na nasze konto. Wszystkie projekty przypisane do tego konta zostaną automatycznie przesłane do aplikacji i możemy równolegle pracować na wielu urządzeniach. Co więcej - wszystkie urządzenia będą obsługiwane jednocześnie więc każda zmiana w jednej aplikacji będzie widoczna natychmiast na pozostałych. Ten sposób działa znakomicie ale ma jednak małą wadę gdy urządzenia obsługiwane są przez inne osoby. Bowiem z każdej aplikacji możemy dowolnie zmieniać a nawet skasować nasz projekt!
Zalecanym sposobem udostępnienia systemu osobom trzecim jest tak zwany SHARED ACCESS. Jest to specjalna funkcja w konfiguracji aplikacji mobilnej. Za jej pomocą możemy sklonować nasz projekt na inne urządzenie mobilne ale z ograniczonym dostępem. Nowy użytkownik może obserwować i sterować naszym projektem bez możliwości jakiejkolwiek zmiany konfiguracyjnej
W tym celu musimy wygenerować kod QR i przesłać go jakoś zainteresowanej osobie .
Funkcja shard access jednak sporo kosztuje - 1000 pkt. W każdej chwili możemy też cofnąć pozwolenie na współdzielenie projektu - ale 1000 pkt. nie zostanie nam zwrócone.
UWAGA - sharing warto uruchomić gdy mamy całkowicie gotowy projekt. Czasami po jego uruchomieniu naniesione później zmiany nie przenoszą się do aplikacji osób współdzielących projekt. I trzeba powtórnie generować kod a czasami załączać sharing ponownie (kolejne 1000 pkt). Ale generalnie funkcja dostępu do naszego projektu osobom trzecim działa super.
Najmniej możemy podziałać z serwerem BLYNKa. Tu albo korzystamy z publicznego serwera udostępnionego przez twórców systemu lub darmo stawiamy swój własny na jakiejkolwiek maszynie z Windowsem lub Linuxem. Niestety wybór jest albo/albo. System w tym zakresie jest mocno monogamiczny. Czy istnieje potrzeba posiadania więcej niż jednego serwera BLYNKa? Moim zdaniem warto mieć taką możliwość - po co ? o tym kiedyś przy innej okazji.
Idea i implementacja funkcji kodu AUTH TOKEN to moim zdaniem niezły przykład zdolności twórczych autorów BLYNKa. I na pewno to jeszcze nie koniec ich możliwości.
Co było i mam nadzieję będzie do okazania.
7
Brak komentarzy:
Prześlij komentarz