Translate:
Informacje
WWW
PLIKI
-
Najnowsze wpisy
Najnowsze komentarze
- Andrzej o Czarne chmury nad BLYNK 1.0
- Marek Marczuk o Czarne chmury nad BLYNK 1.0
- Krzycho o Czarne chmury nad BLYNK 1.0
- Marek Marczuk o Czarne chmury nad BLYNK 1.0
- Marek Marczuk o Czarne chmury nad BLYNK 1.0
Archiwa
- Grudzień 2021 (1)
- Listopad 2021 (1)
- Październik 2019 (1)
- Czerwiec 2019 (1)
- Marzec 2019 (1)
- Styczeń 2019 (1)
- Listopad 2018 (2)
- Październik 2018 (1)
- Sierpień 2018 (1)
- Czerwiec 2018 (1)
- Maj 2018 (2)
- Kwiecień 2018 (4)
- Luty 2018 (4)
- Styczeń 2018 (5)
- Grudzień 2017 (2)
- Listopad 2017 (8)
- Październik 2017 (4)
- Wrzesień 2017 (7)
- Sierpień 2017 (4)
- Lipiec 2017 (1)
Kategorie
- Serwer Lokalny BLYNK (8)
- Zaczynamy (1)
- Ciekawostki (1)
- Aplikacja tel/tablet (15)
- Sterowanie z pulpitu (2)
- 5. Widgety (13)
- EVENTOR (2)
- Znalezione w sieci (1)
- Układy wieloprocesorowe (2)
- Na warsztacie u innych (2)
- komunikaty (2)
- Problemy (1)
- Uncategorized (5)
- 1. Ogólne (5)
- 2. Piny (3)
- 3. Komunikacja (11)
- API WEBHOOK (4)
- kontrola komunikacji (3)
- Nie blokujący BLYNK (3)
- 4. Biblioteki (3)
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
[…] Systemy rozproszone – BLYNK rządzi cz. I […]
Czy powstanie obiecana następna część ?
tak ale zaczekam na nowego BLYNKa
obecna wersja już nie będzie rozwijana
dzięki bardzo ciekawe porady tylko troszkę mało czekamy na więcej
Ooo coś ciekawego… Czekam na dalszą część 🙂