Systemy rozproszone – BLYNK rządzi cz. I

W dobie śmiesznie tanich mikrokontrolerów nie ma większego sensu pakowanie wszystkich funkcji inteligentnego domu w rozbudowany wieloportowy i uniwersalny układ. Nie znam wyników sprzedaży takich płytek jak ARDUINO MEGA ale szczerze wątpię by komuś w domowym IoT był potrzebny jeden moduł  z 56 portami. Ciąganie po domu setek metrów kabli by takie cudo podłączyć do żądanych czujników i elementów wykonawczych uważam za elektroniczny masochizm. O ileż łatwiejsze i bardziej eleganckie jest zastosowanie małych procesorów do realizacji poszczególnych funkcji – ot choćby do odczytu temperatury czy załączania przekaźnika. A dodatkowo przy aktualnych cenach ESP (1 – 2 $/ moduł) taka konfiguracja  będzie grubo tańsza. Jedynie czego potrzebujemy do budowy rozproszonej sieci sterowania to technologii łączenia modułów w jeden system. Dzięki WiFi i BLYNKowi połączenie takie jest i możliwe i bajecznie proste.

Dziś pierwszy z odcinków jak połączyć nasze mikrokontrolery w społeczność na rzecz domowej automatyki.

Możliwe struktury sieci rozproszonych są ściśle związane ze sposobem wymiany danych pomiędzy elementami systemu.

 

BLYNK za względu na obecność centralnego serwera jest klasyczną gwiazdą ze wszystkimi jej zaletami i wadami. Największa zaleta to łatwość zarządzania i kontrolowania całej sieci ( w systemach komercyjnych to wartość bezcenna). Największa wada związana jest z jej największą zaletą – uszkodzenie serwera totalnie rozwala całą strukturę.

BLYNK od początku zakładał jednoczesną współpracę z wieloma procesorami. Jednak początki jak to początki były mocno toporne i mało atrakcyjne w implementacji. Widget BRIDGE miał być odpowiedzią na potrzeby użytkowników budujących sieci rozproszone w oparciu o BLYNKa. Ale z informacji autorów element ten nigdy nie zdobył uznania blynkerów i był (i nadal jest bo istnieje w menu) najrzadziej stosowanym widgetem. Nic dziwnego – trudność w zrozumieniu logiki działania i niewielka elastyczność zniechęcała do jego użytkowania.

Ale też od samego początku BLYNKa istniał prosty sposób połączenia wielu mikrokontrolerów w jeden system.

Połączenie za pomocą AUTH

Kod AUTH jest jednocześnie i sygnaturą pozwalającą zidentyfikować użytkownika końcowego i kodem dostępu do serwera BLYNK. W pierwotnych założeniach każdy z mikrokontrolerów przyłączanych do BLYNKa ma swój własny niepowtarzalny kod AUTH. Szybko jednak zauważono, iż nie ma większych przeszkód by ten sam kod umieścić w kilku modułach. Tracimy co prawda niektóre z funkcji BLYNKa np. automatyczną detekcję utraty połączenia urządzenie – serwer, ale jest to najszybszy, najtańszy (wręcz bezkosztowy) i najprostszy sposób budowy sieci rozproszonej.

Jak to wygląda w praktyce? Zobaczmy na przykładzie trzech modułów ESP-01S: jednego przekaźnika i dwu DHT11.

W tej konfiguracji serwer nie ma pojęcia ile modułów z tym samym kodem jest do niego przyłączonych.  Komunikacja ze wszystkimi modułami odbywa się jednocześnie tzn. ten sam komunikat jest wysyłany do każdego z mikrokontrolerów.  Nie można też bez znajomości kodu procesorów stwierdzić, który moduł jest nadawcą wiadomości odbieranej przez serwer.

A jednak w dosyć prosty sposób da się zarządzać taką siecią i w jednoznaczny sposób identyfikować źródła i cele informacji. Trzeba tylko zrezygnować ze stosowania pinów rzeczywistych a całość komunikacji oprzeć na wirtualnych pinach. Jeśli każdy z modułów zarządza „swoją” pulą pinów wirtualnych bez problemów możemy zindywidualizować komunikację w takim układzie. Na rysunku piny v10, v20 i v30 jednoznacznie wskazują, który z mikromodułów zarządza informacją przesyłaną tym kanałem. Pin v1 jest wspólny dla wszystkich i może służyć do wymiany danych pomiędzy procesorami.

Jakie są ograniczenia takiej konfiguracji?

• Jak już wspomniałem do komunikacji trzeba stosować wyłącznie piny wirtualne. Piny rzeczywiste teoretycznie da się wysterować o ile procesor modułu jest zgodny z wybranym w aplikacji. Ale można połączyć w sieć różne typy mikrokontrolerów i odwzorowanie pinów rzeczywistych może być nieprawidłowe.
• Wraz ze wzrostem liczby modułów zmniejsza się dostępna pula pinów na jeden układ Co prawda pulę 128 pinów trudno jest wyczerpać w typowych domowych zastosowaniach ale już dla rozległych komercyjnych systemów jest to poważne ograniczenie.
• Jak wspomniałem nie jest możliwa detekcja uszkodzenia modułu standardowymi procedurami BLYNKa. Należy stworzyć własny programowy system testowy pozwalający online kontrolować sprawność wszystkich elementów systemu.

Nie są to jednak poważne utrudnienia więc budowa sieci na wspólnym AUTH jest dosyć popularna.

Co zyskujemy?

• Sterowanie wieloma modułami ale jednym systemem domowej automatyki.
• Niezawodność – uszkodzenie jednego z modułów wyłącza tylko jedną funkcję.
• Łatwość modyfikacji – zmiana w jednej funkcjonalności praktycznie nie ma wpływu na pozostałe.
• Banalnie prosta rozbudowa – po prostu dokładamy kolejny mikroprocesorowy klocek i wpinamy go w sieć powiązań np. poprzez widget EVENTOR

 

Komunikacja w ramach BLYNK

Przesył danych z aplikacji do urządzeń jest standardowy. Wirtualny pin przypisany do widgetu dostarczy informację do każdego z modułów odbierającego ten pin. Nie ma żadnych ograniczeń co do ilości „odbiorców”

Przesył danych z urządzeń do aplikacji podlega ostrzejszym rygorom. Zasadniczo nie należy dublować w mikrokontrolerach nr pinów wirtualnych wysyłających informacje do telefonu – nie wiadomo w jakiej kolejności dotrą one do serwera i która wartość będzie jako końcowa wyświetlana w aplikacji. Reguła jeden pin – jeden modu w tym przypadku jest nad wyraz wskazana

Przesył danych pomiędzy modułami jest najbardziej złożony. W tym celu należy wykorzystać możliwość zapamiętywania danych przez serwer. Każde wywołanie funkcji

Blynk.virtualWrite(nrPin, wartość);

zapisuje na serwerze wartość przypisaną do numeru Pinu. Teraz daną można już wczytać do drugiego mikrokontrolera. Istnieje rozkaz pobrania przez mikrokontroler danych przechowywanych na serwerze choć jest on ukryty pod nieco mylącym rozkazem

Blynk.syncVirtual(nrPin)

Polecenie stosowane jest przede wszystkim do synchronizacji zawartości wirtualnych pinów urządzenia z serwerem po restarcie lub utracie komunikacji. Synchronizacja wszystkich pinów wygląda tak

BLYNK_CONNECTED() {

Blynk.syncAll();

}

Dla cyklicznego odczytywania pinu V0 z serwera należy timerem wywoływać procedurę (nie należy tego umieszczać w pętli głównej bo pewnikiem zapchamy serwer)

Blynk.syncVirtual(V0)

a w kodzie umieścić procedurę zapisu pinu wirtualnego do zmiennej programu

BLYNK_WRITE(V0) {

int pinData = param.asInt();

}

I to zasadniczo wszytko co musimy wiedzieć by efektywnie spiąć nasze mikrokontrolery w jedną sieć jednym kodem AUTH.

Przykładowe programy dla trzech modułów ESP-01S zamieściłem na githubie

A to widok telefonicznej aplikacji dla sieci sprzężonych BLYNKiem  tych trzech mikrokontrolerów.

 

 

Przycisk, vLED i wartości h1, h2 (piny V0, V10, V15 i V16) powiązane są z modułem przekaźnika. Wartości h1 i h2 pobierane są z modułów DHT11 via serwer BLYNK poprzez współdzielone piny V11 i V21. Do modułów DHT11 dowiązane są piny V3,  V11, V12 oraz V4, V21, V22 Obsługują one widgety LEDy i wyświetlacze wielkości hum i T w aplikacji . LEDy po prawej stronie sygnalizują prawidłowe połączenie z urządzeniami systemu i zastępują oryginalny blynkowy system informacji o połączeniu z modułami.

Za pomocą widgetu EVENTOR zmieniam stan przycisku V10 (steruję przekaźnik) w funkcji wilgotności z pierwszego czujnika DHT11 (V11). Graniczna wartość przełączania to 40%

Dokładniej widać to wszystko na filmie

 

BLYNK w powyższej konfiguracji świetnie sobie radzi z obsługą wielu niezależnych kontrolerów rozsianych po naszym domu tworząc z tego jeden system domowej automatyki. W następnych odcinkach – o innych sposobach realizacji tego samego zadania za pomocą BLYNKa.

46