PIC32MM i moduł Ethernetowy Wiznet W5500 - komunikacja z chmurą za pomocą MQTT ,zajęcia praktyczne cz.5

W części nr 4 wątku o komunikacji z chmurą pokazywałem prostą metodę rozmowy z chmurą opartą na samym protokole TCP i strumieniu znakowym.

Od strony chmury komunikacja taka obsługiwana była w warstwie aplikacji przez protokół Telnet. Metoda ta znalazła uznanie wśród czytelników bloga, nie bez przyczyny, jest tak prosta , że już prościej się nie da. Ale to nie koniec niespodzianek dotyczących metod komunikacji z chmurą. Na deser zostawiłem najbardziej spektakularną metodę opartą o protokół MQTT. Jest to metoda obsługiwana praktycznie przez wszystkie chmury, jeśli przez jakąś nie jest obsługiwana to znaczy, że ta chmura nie warta jest uwagi z punktu widzenia ekosystemu IoT. Zapraszam do podróży po MQTT w aspekcie praktycznym.

Na początek trochę teorii , którą trzeba poznać, tutaj odsyłam do wikipedii MQTT. oraz do tego fajnego artykułu : artykuł o MQTT

Moim skromnym zdaniem jedną z przesłanek do stworzenia protokołu MQTT była myśl o odciążenie internetu :). Wyobraźmy sobie sytuację w której miliardy urządzeń IoT zaczną odpytywać w krótkich interwałach czasu serwer o dane i przy każdym zapytaniu będą wysyłane nagłówki HTTP, jak nic rura się przytka. Taki efekt przytkania generują np. ataki hakerskie typu DDos. Znany jest przypadek kiedy sieć miejskich kamer internetowych została wykorzystana do takiego ataku na sieć korporacji. Czego efektem było zawieszenie działania firmy na czas ataku czyli firma ponosiła straty w tym czasie.

I tu dochodzimy do sedna różnicy pomiędzy MQTT a HTTP. W dotychczas znanym przez nas modelu komunikacji opartym np. o HTTP  urządzenie IoT aby uzyskać informację o stanie np.zmiennej w chmurze musi wysłać zapytanie o nią. W tym łańcuchu komunikacji brakuje informacji ze strony serwera , że nastąpiła zmiana wartości zmiennej. My musimy po prostu cały czas próbkować stan zmiennej w chmurze i wysyłać nadmiarowe zapytania. A co by było gdyby to serwer poinformował klienta (urządzenie IoT) , że nastąpiła zmiana parametru/zmiennej w chmurze i taka informacja razem z wartością parametru/zmiennej dotarła by do klienta. Taka operacja właśnie zachodzi w uproszczeniu w MQTT. W której zadaniem klienta jest tylko otworzyć połączenie z chmurą(brokerem) i nasłuchiwać , jednocześnie poinformować serwer, że jest subskrybentem danego tematu(parametr/zmienna) lub przesłać dane jeśli jest publikatorem jakiegoś tematu. Klient może być jednocześnie subskrybentem i publikatorem.

Dla rozjaśnienia zagadnienia posłużę się poniższym rysunkiem zapożyczonym z tego  artykułu .

Rysunek doskonale obrazuje zasadę działania MQTT. Mając już jakąś teoretyczną wiedzę , zakładam , że czytelnik zapoznał się z wiedzą zawartą w linkach na początku artykułu, możemy przystąpić do części praktycznej.

Tylko zobrazowanie w sposób praktyczny może nas w pełni przybliżyć do zrozumienia zagadnienia.  Naszym brokerem MQTT jest chmura Ubidots w której mam darmowe konto Ubidtos Steam. W chmurze mam utworzone urządzenie o nazwie pic32 a w nim jedną zmienną temperaturasalon. To wszystko jak w poprzednich artykułach, również część sprzętowa nie ulega zmianie, nadal operuję na zestawie PIC32MM (Płytka Curiosity Microchipa) + moduł Winzet W5500 firmy Mikroelektronika + konwerter UART/USB.
Tak swoją droga moduł W5500 jest teraz w promocji "christmas-owej" 20%.
Powyższy zestaw sprzętowy jest naszym klientem w modelu komunikacji MQTT.

Aby odtworzyć w praktyce model komunikacji MQTT potrzebujemy po stronie klienta (naszego urządzenia PIC32MM+W5500)   biblioteki obsługującej ten protokół. Takie biblioteki są dostępne w różnych językach m.in i w języku C . Najbardziej popularną biblioteką jest klient Paho i teoretycznie taką bibliotekę moglibyśmy zaimplementować na nasze potrzeby do komunikacji z naszą chmurą ale w tym przypadku byśmy musieli się trochę namęczyć. Na szczęście firma Wiznet oferuje bibliotekę kliencką MQTT dla modułu W5500 z interfejsem do klienta Paho. . Biblioteka ta jest jednym z elementów oficjalnej biblioteki firmy Wiznet o nazwie  ioLibrary_Driver .Poszczególne pliki jakie trzeba zaimportować do struktury projektu w MPLABX-IDE aby mieć funkcjonalność klienta MQTT pokazuję na rysunku poniżej :

Wszystkie niezbędne pliki będą znajdować się w programie, który będzie efektem końcowym tego artykułu i będzie do pobrania z GitHub.

Do nawiązania połączenia z chmurą Ubidots (w przypadku MQTT chmura jest naszym brokerem) potrzebujemy adresu IP chmury i nr portu na którym usługa jest udostępniona oraz nasz Token "chmurowy". Te dane to odpowiednio :

industrial.api.ubidots.com - adres IP : 169.55.61.243

numer portu dla usługi MQTT non-TLS (bez szyfrowania) - 1883

Powyższe dane pozyskałem z dokumentacji chmury Ubidots. Token natomiast musimy sobie odczytać z chmury w panelu klienta, pokazywałem już w innym artykule gdzie tego szukać.

Fizyczna postać komunikatu MQTT będzie podobna do poznanej już metody TCP i stringów znakowych. Na pewno nie będzie tutaj nagłówków tak jak w HTTP. Ale my nie musimy troskać się formowaniem postaci komunikatu, zrobi to za nas API biblioteki klienckiej MQTT. My tylko będziemy jak Świstaki zawijać w papierek  same dane np. wartość zmiennej temperaturasalon a API uformuje  nam całą postać komunikatu. W celach naukowo-dydaktycznych podejrzymy jednak jak fizycznie wyglądają komunikaty MQTT, zarówno te wysyłane przez nas jak i te , które wyśle do nas serwer czyli nasza chmura. Sam jestem ciekawy jak to będzie wyglądać.

Na tym etapie pozostaje zapoznać się z biblioteką kliencką MQTT i spróbować wysłać coś do chmury jako publisher a w następnej kolejności co będzie bardziej interesujące będziemy nasłuchiwać jako subscriber. Przy czym na cele subskrypcji powołamy sobie w chmurze zmienną typu przełącznik czyli on/off tak abyśmy mogli w chmurze zmieniać jej stan a po stronie klienta czyli PIC32MM+W5500 mogli zobaczyć i upewnić się czy serwer prześle nam komunikat po zmianie stanu zmiennej ,bo na tym właśnie polega różnica w stosunku do modelu komunikacji HTTP.

Na razie potrzebuję czasu na zapoznanie się z biblioteką kliencką MQTT i ogarnięciu jej, mam nadzieję, że będzie współpracować z chmurą Ubidots. Pisząc ten artykuł sam się uczę.

W międzyczasie przygotujemy sobie od strony chmury Ubidots, zmienną , która będzie reprezentowała zdalny przełącznik typu on/off. Wykorzystam go do testów biblioteki MQTT. Na wszelki wypadek pokażę jak powołać taką zmienną w chmurze Ubidots. Startowy obrazek po zalogowaniu się do chmury :

W chmurze mamy utworzoną tablicę MojaTablica a na niej pole reprezentujące zmienną temperaturasalon , która z kolei przyporządkowana jest do urządzenia pic32. To wszystko tworzyliśmy w jednym z poprzednich artykułów i tu nic się nie zmienia. Teraz chcemy sobie dodać do tablicy pole typu przełącznik i do tego pola przyporządkować zmienną , którą zaraz utworzymy.

Wchodzimy do zakładki Devices i tam wybieramy Devices.

Mamy jedno urządzenie o nazwie pic32. Wchodzimy do niego "klikając" w nazwę.

Pokazuje nam się zawartość urządzenia pic32 czyli zmienne jakie są do niego przyporządkowane. Mamy tutaj tylko jedną zmienną temperaturasalon. Aby utworzyć kolejną zmienną wybieramy pole Add Variable a następnie opcję RAW.

Zostanie utworzona nowa zmienna, nazwałem ją Switch.

Wchodzimy do niej aby nadać jej nazwę dla API, czyli tą nazwę , którą posługiwać się będziemy podczas komunikacji z chmurą.

I tu mała niespodzianka bo chmura sama nadała nazwę dla API bazując na wpisanej nazwie zmiennej. Czyli w polu pomarańczowym na poprzednim obrazku wpisałem nazwę Switch a chmura przyporządkowała jej nazwę w API - switch  (z małej litery). Nic więcej tutaj nie musimy podawać aczkolwiek możemy ale nie musimy podać zakres zmiennej From: 0 i to: 1 . Bo to i tak ustawi nam automatycznie pole na tablicy. Opuszczamy widok zmiennej Switch i wracamy do naszej tablicy czyli widoku głównego w naszeh chmurze. W tym celu "klikamy" w górnym lewym rogu napis ubidots.
W widoku głównym wybieramy po prawej stronie niebieski plusik. Rozwinie sie nam po prawej stronie wybór z ikonkami. Wybieramy ikonkę Switch, jeden raz "klikając".

Wyskoczy nam kolejne okienko :

W powyższym okienku wybieramy opcję Add Variables, wyskoczy nam okienko z nazwą naszego urządzenia w chmurze pic32. "Klikamy" w nazwę urządzenia aby rozwinęła nam się jego zawartość czyli przyporządkowane zmienne :

Wybieramy zmienną Switch i zatwierdzamy wybór zielonym "ptaszkiem". Wyskoczy nam poniższe okienko, które zatwierdzamy zielonym "ptaszkiem". Oczywiście możemy tam zmieniać sobie co dusza zapragnie, np zamiast proponowanych komunikatów Off/On inne nazwy.

Efektem naszych działań jest pojawienie się na naszej tablicy nowego pola o nazwie Switch.

Stanem naszego przełącznika możemy sterować z chmury, z urządzenia mobilnego czy też naszego zestawu PIC32MM+W5500. Zapomniałem wspomnieć, że wszystkie pola na naszej tablicy, łącznie z tablicą można "customizować" w/g własnego gustu i upodobań.

Teraz chciałbym przedstawić zagadnienie poboczne związane z MQTT ale fajne , ciekawe i z aspektami edukacyjnymi. Mianowicie podczas wieczoru zapoznawczego  z biblioteką MQTT , której rozpoznanie cały czas trwa. Zaszła potrzeba sprawdzenia innym sposobem czy komunikacja z chmurą Ubidots za pomocą protokołu MQTT w ogóle działa. A tutaj z pomocą przyszła mi wtyczka do przeglądarki Chrome o nazwie MQTTlens. Za pomocą tej wtyczki możemy w bardzo prosty sposób sprawdzić działanie MQTT  w naszej chmurze. A co konkretnie chcę sprawdzić ? chcę się upewnić czy zostanie nawiązana komunikacja z chmurą za pomocą protokołu MQTT oraz czy nasz przycisk Switch działa i czy jego subskrypcja da pożądany efekt w postaci komunikatów od serwera (chmura) do klienta (przeglądarka chrome).

Otwieramy przeglądarkę Chrome , wpisujemy w pasek wyszukiwarki MQTTlens :

wchodzimy w pierwszy link , efekt jak poniżej :

i wybieramy Add to Chrome  , aplikacja się zainstaluje i wskoczymy do obrazka jak poniżej gdzie wybieramy ikonkę z lupą :

Po chwili uruchomi się aplikacja MQTTlens jako samodzielne okienko odpięte od przeglądarki :

Wybieramy z lewej strony przy napisie Connections , plusik. Czyli dodajemy połączenie. Wyskoczy nam okienko jak poniżej w którym trzeba wpisać dane :

to co musimy wpisać w powyższym okienku to :

connection name - byle co,
Hostname : industrial.api.ubidots.com (adres chmury Ubidots, my w programie zamiast tego operujemy adresem IP 169.55.61.243),
Username i Password :  Nasz Token "chmurowy", każdy wbija swój nie wbijać mojego bo będziecie moim switchem sterować  :)

Po wypełnieniu okienka  danymi wybieramy w dolnym prawym rogu Create Connection. Jeśli wszystko jest w porządku pojawi się okienko jak poniżej :

Naszym zamiarem jest subskrypcja przełącznika Switch w chmurze Ubidots. Aby dokonać subskrypcji czyli poinformować serwer chmury , że jesteśmy zainteresowani odbiorem tej danej i monitorowaniem jej stanu , wypełniamy pole Subscribe stringiem : /v1.6/devices/pic32/switch/lv
Taki zapis wynika z dokumentacji chmury w dziale MQTT. Odwołujemy się nim do urządzenia pic32 a w nim do naszego Switcha, którego nazwa dla API to switch.

Po wypełnieniu pola Subscribe, wybieramy po prawej zielony napis SUBSCRIBE. Na dole pojawi się panel z informacją o stanie subskrypcji naszego tematu :) czyli informacje co się dzieje na naszym przełączniku Switch.

Message: 0 informuje nas , że przełącznik w chmurze jest w pozycji OFF czyli 0 czyli wyłączony :).
Teraz czeka nas przednia zabawa , sterowanie naszym przełącznikiem Switch w chmurze i obserwowanie w aplikacji MQTTlens napływających komunikatów. Logujemy się do chmury (każdy do swojego konta a nie mojego :) ) i zmieniamy stan naszego przełącznika Switch na wartość ON czyli 1. W tym celu "klikamy" w obrys panela z ikonką przełącznika na Tablicy w chmurze. Efekt jak poniżej :

Zobaczmy co się tutaj stało, w chmurze widzimy zmieniony stan przełącznika Switch na ON (1), poprzedni stan to OFF (0). Praktycznie w tym samym momencie co zmiana stanu przełącznika w chmurze otrzymaliśmy w aplikacji MQTTlens , która jest tutaj klientem, komunikat Message :1. To działa naprawdę szybko i rewelacyjnie . Jestem pod dużym wrażaniem szybkości przesyłania komunikatów z chmury do klienta czyli aplikacji MQTTlen to są milisekundy.

Dla uświadomienia jak genialnym protokołem w swojej prostocie i filozofii działania jest MQTT. Porównajmy jak taka komunikacja wyglądałaby w klasycznej metodzie opartej o protokół HTTP. Aby wykryć stan przełącznika w chmurze klient musi wysłać do serwera chmury zapytanie HTTP, przedstawię to obrazowo : hey chmura jaki masz stan Switcha , chmura odpowiada np. OFF (0) , oki mówi klient rozłączamy się i ponownie zapytam za 5 sekund lub inny dowolny interwał ale niezbyt szybki aby nie przyczynić się do "smogu" internetowego :). Taka zwłoka w ciągłym odpytywaniu serwera o stan Switcha powoduje bezwładność w wykryciu zmiany stanu przełącznika .Stąd wniosek, że HTTP nie jest optymalnym rozwiązaniem do współpracy z ekosystemem IoT. Wiem , że ludzie tego jednak używają i się cieszą , że w ogóle to działa :) a reszta to pierdoły :).
 
My jednak wiemy , że przy pomocy MQTT zrobimy to najbardziej optymalnie i najlepiej jak tylko pozwala na to dostępna obecnie technologia.

Pierwsze testy biblioteki MQTT mam za sobą - działa fajnie a nawet bardzo fajnie. Gdybym napisał , że wszystko szło gładko to bym skłamał. Biblioteka a w szczególności przykład jaki w niej został zawarty niestety nie chciał uruchomić się od przysłowiowego strzała. Jedną z przyczyn był zbyt mały bufor do wysyłanych danych co może było drobnostką ale drugi aspekt z jakim przyszło mi się zmierzyć już nie był trywialny. Mianowicie aby ustanowić połączenie z chmurą Ubidots nie wystarczyła jedna próba wywołania funkcji bibliotecznej ConnectNetwork() , chmura odrzucała każde dwie pierwsze próby ustanowienia połączenia a dopiero na każdej trzeciej próbie takie połączenie było skuteczne i było utrzymywane , niezawodnie jak u Zawiszy :). Nie wiem z czego to wynika , że chmura odrzuca każde dwie propozycje randki z naszym modułem W5500 . Przyjąłem , że ten model tak ma i trzeba się dostosować do tego. Aby z problemem sobie poradzić musiałem zmodyfikować funkcję biblioteczną ConnectNetwork() oraz dołożyć pętlę oczekującą na poprawne nawiązanie połączenia z chmurą. Dopiero wtedy wszystko zaczęło działać jak należy a nawet lepiej. Na obrazkach poniżej pokazuję te dwa newralgiczne miejsca czyli obraz zmienionej funkcji ConnectNetwork() w pliku mqtt-interface.c i wspomnianą pętlę oczekującą while.

Przejdę do krótkiej analizy programu jaki poczyniłem na okoliczność testu komunikacji MQTT z chmurą Ubidots. Na początek napiszę co robi program ?
W programie otwieramy połączenie z chmurą Ubidots. Parametry połączenia to od strony modułu W5500 :

port : 5000
numer gniazda : 0

od strony chmury Ubidots :

port : 1883
adres IP : 169.55.61.243


Po nawiązaniu połączenia. Dokonujemy subskrypcji zmiennej switch w  chmurze (zmienną switch uprzednio utworzyliśmy w urządzeniu o nazwie pic32) . Topic subskrypcji to : /v1.6/devices/pic32/switch/lv . Każda zmiana stanu Switcha w chmurze powoduje odebranie jej  po stronie PIC32MM+W5500, wyświetlenie na konsoli wartości i zasterowanie diody LED na pinie RC13. Czyli krótko mówiąc poprzez subskrypcję Switcha, sterujemy on-line diodą LED za pomocą przełącznika w chmurze. Działa to doskonale. Kolejną czynnością , którą robi program to publikowanie do chmury danej temperaturasalon. Dana zmienia się w zakresie od 1 do 10. Taką zmianę zobaczymy co ok 3 sekundy po stronie chmury.
Do programu dołączyłem mechanizm wykrycia braku połączenia z chmurą. Zrealizowałem to za pomocą cyklicznego (co ok.10 sekund) sprawdzania stanu gniazda na którym zostało zawiązane połączenie. To na wypadek jakby pies nam przegryzł kabel Ethernetowy lub piorun walnął w serwer po stronie chmury etc. Wykrycie braku połączenia nastąpi ze zwłoką zbliżoną do keepAliveInterval czyli ok 60 sekund, po wykryciu stanu braku połączenia nastąpi automatyczny reconnect łącznie z odnowieniem subskrypcji.

Oczywiście nadmienię, że program nie jest wybitnym dziełem sztuki, raczej bliżej mu do sztukanterii :). Starałem się jednak w miarę w prosty sposób wdrożyć w nim dwie podstawowe funkcje komunikacji MQTT czyli Subskrypcja i Publikowanie oraz namacalnie przekonać się jak to działa.

Przyjrzyjmy się wybranym fragmentom programu :

Na początek ważna informacja, biblioteka MQTT wymaga do swojego działania odliczania czasu z interwałem 1ms. Użyłem do tego timera TMR1. Poniżej pokazuję ciało funkcji callback Timera  do której dołączyłem funkcję biblioteczną MQTT - MilliTimer_Handler(), którą trzeba wywoływać co 1ms.

Poniżej ciało struktury pomocniczej opts gdzie przechowujemy dane niezbędne w procesie "logowania" do chmury Ubidots, takie jak nasz Token chmurowy, adres IP i port chmury. Tutaj ważna uwaga , kanon komunikacji MQTT wymaga podania nazwy użytkownika (username) i hasła (password). W obu przypadkach podajemy nasz Token "chmurowy".

Poniżej zaznaczyłem kod w którym deklarujemy dwie struktury n i c jedna o typie Network a druga o typie MQTTclient. Komunikacja za pomocą naszej biblioteki MQTT wymaga powołania tych elementów. Pierwszy z tych elementów służy do obsługi wymiany danych pomiędzy modułem W5500 a biblioteką MQTT a drugi potrzebny jest bibliotece w procesie obsługi nowego klienta.

Poniżej sekwencja kodu , która realizuje nam inicjację wszelkich niezbędnych czynności wymaganych przez bibliotekę MQTT do otwarcia aktywnego połączenia z chmurą Ubidots , która jest jednocześnie naszym Brokerem MQTT. Po pomyślnym wykonaniu tego fragmentu kodu możemy już Subskrybować i Publikować treści.

Funkcja realizująca Subskrypcję tematu : /v1.6/devices/pic32/switch/lv czyli naszego Switcha w chmurze wygląda jak poniżej :

W środku mamy funkcję MQTTSubscribe() , jednym z jej parametrów jest wskaźnik na funkcję - messageArrived(), która realizuje nam obsługę odebranej wiadomości od naszego Switcha. A obsługa odebranej wiadomości wygląda jak poniżej :

Jeśli od Switcha przyjdzie wiadomość o postaci : 0 to zgasimy diodę LED na naszej płytce PIC32MM Curiosity na pinie RC13 , jeśli wiadomością będzie : 1 to zapalimy diodę LED.

Zerknijmy jak wygląda pętla główna :

W pętli głównej mamy funkcjonalnie trzy elementy :

1. wywołanie funkcji bibliotecznej  MQTTYield() - monitoruje przepływ informacji z/do chmury w tym obsługa pingów.

2. wywołanie co ok 3 s funkcji PublishTopic(), która przesyła do chmury do zmiennej temperaturasalon dane z zakresu 1...10.

3. sprawdzanie co 10 s czy gniazdo połączeniowe w naszym przypadku gniazdo nr 0 nie zostało zamknięte. Jeśli tak to wykonaj sekwencję startową (reconnect) od etykiety START w dół.

Poniżej ciało funkcji publikującej zmienną temperaturasalon:

W funkcji publikującej powołujemy nowy obiekt typu MQTTmessage o nazwie message_temperaturasalon. Wypełniamy go niezbędnymi danymi i za pomocą funkcji bibliotecznej MQTTPublish(), wysyłamy do modułu W5500 a moduł dalej do chmury. Postać danej wysyłanej do chmury musi wyglądać zgodnie z dokumentacją chmury tak : {"temperaturasalon": 27} gdzie 27 to wartość zmiennej.

Efekt działania programu od strony chmury i wizualizacja na terminalu wygląda jak poniżej :

Na terminalu widzimy akcję od momentu podłączenia kabla ethernetowego do modułu W5500 (połączenie z routerem LTE) . Najpierw zostaje nawiązane stabilne połączenie z chmurą o czym informuje nas komunikat : Open MQTT Broker connect Success, po czym wysyłamy do chmury informację, że jesteśmy Sybsykrentem naszego Switcha w chmurze. W odpowiedzi otrzymujemy aktualny stan Switcha - 0. Kolejne informacje to komunikaty związane z publikowaniem do chmury danej temperaturasalon. Dana zmienia się co ok 3 s w zakresie 1...10 a efekt widzimy w chmurze w polu Temperatura Salon. Między komunikatami pojawia się samotna jedynka :) to oznacza , że zmieniłem stan Switcha w chmurze na ON .
Sterowanie Switchem oraz podgląd pola Temperatura Salon możemy oczywiście realizować z dowolnego miejsca na kuli ziemskiej z telefonu lub innego urządzenia mobilnego podłączonego do internetu.

W zasadzie tym artykułem na razie kończę zabawę z modułem W5500. Moduł jest z grubsza przeze mnie rozpoznany i opanowany. W kolejnych artykułach pokazałem jak przy pomocy tego modułu możemy fajnie flirtować z chmurą na różne sposoby. W dalszej kolejności trzeba by było pójść w kierunku metod obiegu danych w wewnętrznej sieci i wysyłanie tych danych przez W5500 do chmury, a tutaj widzę dwóch kandydatów - sieć CAN lub sieć RF oparta na modułach radiowych np SI4463.
Z płytką PIC32MM Curiosity Microchipa możemy zrealizować te dwa kierunki bez problemu, mamy jeden wolny slot na moduły np. z kontrolerem CAN lub SI4463. Do tego jak byśmy zapodali prostego RTOS-a a mam takowego w zanadrzu to myślę , że by była fajna i twórcza zabawa. No ale zobaczymy co dalej z tym zrobię.

W linkach poniżej znajduje się projekt , który wgrałem na GitHub. Ściągamy go do MPLABX-IDE za pomocą Team --> Remote --> Clone lub w konsoli Linuxa :

git clone https://github.com/PICmajster/PIC32MM_W5500_MQTT.git

Pozdrawiam
picmajster.blog@gmail.com

Linki:

Chmura Ubidots - dokumentacja
Program na GitHub- Send data to Ubidots

mqtt