PIC32MM i moduł Ethernetowy Wiznet W5500 - komunikacja z chmurą za pomocą HTTP i API REST ,zajęcia praktyczne cz.3

Czas na jedno z ciekawszych przedsięwzięć związanych z wykorzystaniem modułu ethernetowego W5500 firmy Wiznet. Tematyka chmur zaprząta moje myśli od jakiegoś czasu. Z zazdrością patrzyłem na moduły IoT np. takie jak PIC IoT firmy Microchip, które potrafiły wymienić dane z chmurą w obie strony. Mankamentem jak dla mnie w przypadku tego typu modułów jest ograniczenie współpracy do jednej firmy "Chmurowej" tutaj akurat Google. Jest to podyktowane wykorzystaniem urządzenia kryptograficznego ATECC608A zwiększającego poziom bezpieczeństwa przesyłu danych. Gdzie zatem wolność wyboru ? jedna chmura i koniec ?. Jeśli nie prezentujemy danych wrażliwych i sprawy bezpieczeństwa nie są kluczowe w naszym projekcie sieciowym to nie ograniczajmy się w wolności wyboru :). Duet PIC32MM + W5500 skomunikuje się z każdą chmurą, zatem niech żyje wolność :). W artykule pokażę na przykładzie wybranej chmury jedną z metod wysyłania i pobierania danych z chmury. Radość z pierwszego uaktualnienia danej w chmurze była ogromna :). Takiej satysfakcji nie zastąpi żaden gotowy moduł przysposobiony przez producenta do komunikacji z chmurą :)

Chmura jaką wybrałem za cel wymiany danych z naszym modułem W5500 to chmura Ubidots. Chmura ta jest bardzo prosta w obsłudze i posiada darmowy plan Ubidots STEM .Przy zakładaniu konta nie jesteśmy zmuszani do podania numeru karty kredytowej tak jak u globalnych ździerców typu Google, Amazon. Do ćwiczeń i zabaw chmurowych, Ubidots jest bardzo fajnym obiektem. Dużą zaletą jest tu przyjazna dokumentacja, która jest niezbędna do tego aby nawiązać współpracę z chmurą i wymienić z nią dane.

Pierwszym krokiem w naszej zabawie będzie założenie konta w Ubidots, ja już takowe posiadam, więc nie pokażę tego procesu . Nie mniej jest to proste jak budowa T-34 :). Jestem pod wrażeniem rosyjskiego filmu reklamującego produkt i jego obsługę o tym tytule, stąd to porównanie :). Po zalogowaniu na swoje konto w Ubidots zobaczymy pusty ekran jak poniżej :

Aby przysposobić chmurę do współpracy musimy zrobić w niej z grubsza trzy rzeczy :

1. powołać do życia nowy Dashboard czyli tablicę/ekran na którym będziemy umieszczać widgety reprezentujące np. dane pomiarowe, stan przełączników, slidery, wykresy z jednego lub wielu urządzeń etc.

2. powołać do życia urządzenie (Devices) do którego będą przypisane zmienne (Variables) (np. jakieś czujniki). Devices od strony chmury jest urządzeniem wirtualnym nie fizycznym. Fizyczne urządzenie czyli nasz MCU + moduł W5500 komunikuje się (wymienia dane) z wirtualnym chmurowym urządzeniem.

3. powołać do życia element (Variables), który reprezentuje dane np z jakiegoś konkretnego czujnika temperatury podłączonego do fizycznego urządzenia.

Najpierw sobie utworzymy Dashboard ,w tym celu klikamy" ikonkę Add Dashboard. Po prawej stronie wyskoczy okno w którym wpisujemy tylko nazwę naszego Dashboard , ja wpisałem MojaTablica. Zatwierdzamy ptaszkiem na dole po prawej.

W efekcie utworzyliśmy w chmurze Dashboard o nazwie MojaTablica

Teraz czas na utworzenie wirtualnego urządzenia, nazwiemy go pic32. W tym celu na górze rozwijamy menu o nazwie Devices i tam wybieramy opcję  Devices :). Wyskoczy nam okno jak poniżej :

W powyższym oknie "klikamy" plusik niebieski na górze po prawej Add new Devices . Po "kliknięciu" w plusik wyskoczy po prawej okno jak poniżej :

Trochę sporo opcji jak na początkującego "chmuromaniaka". Nie bójmy się jednak , dobra wróżka podpowiada aby wybrać z tego galimatiasu ikonkę Blank Devices. Wybieramy zatem tę opcję i pokazuje nam się widok jak poniżej w którym wpisujemy nazwę pic32 i zatwierdzamy "ptaszkiem" na dole.

Utworzony zostaje nasz wirtualny Devices o nazwie pic32 .Uff połowę roboty za nami :). W darmowej wersji chmury mamy możliwość utworzenia trzech Devices.

Teraz czas na utworzenie Variables . którą docelowo powiążemy np z czujnikiem temperatury , który będzie skorelowany z naszym Devices. Oczywiście czujnik temperatury też po stronie chmury jest wirtualny czyli nie zmierzy nam temperatury panującej w chmurze tylko przyjmie dane wysłane z naszego fizycznego urządzenia z poza chmury.
"Klikamy" w nazwę naszego Devices w ostatnim widoku w jakim się znaleźliśmy.
Pokaże nam się okienko jak poniżej :

Po lewej możemy jeszcze uzupełnić sobie dane dotyczące naszego Devices np. Property gdzie możemy opisać dodatkowe właściwości dla naszego urządzenia np jego lokalizację w postaci Piętro1/Salon. My jednak skupiamy się na utworzeniu Variables , w tym celu wybieramy Add Variable w kwadracie otoczonym przerywaną linią. Pojawi się po prawej stronie opcja wyboru Raw lub Sythetic. Wybieramy Raw.

Po wybraniu Raw zostanie utworzony nowy obiekt Variables , reprezentowany przez kwadrat z pomarańczowym wykończeniem :)

"Klikamy" w ten utworzony kwadrat i przechodzimy do "wnętrza" naszej zmiennej :

We wnętrzu naszej zmiennej podaję nazwę  w polu Descritpion - Temparatura Salon, API Label - temperaturasalon i w polu pomarańczowym - Temparatura Salon. Dodatkowo określam zakres zmiennej od 0 do 100 .

Do zmiennej z neta będziemy odwoływać się po nazwie umieszczonej w API Label lub po kluczu ID.

Ostatnią czynnością w chmurze będzie uwidocznienie naszej zmiennej na tablicy Dashboard. Przechodzimy zatem do naszej tablicy , "klikając" w lewy górny napis Ubidots.

W powyższym widoku  "klikamy" w okienko opisane Add new Widget . Po prawej wyskoczy nam okienko z językiem obrazkowym jak poniżej :

My chcemy aby nasza zmienna Variables o nazwie Temperatura Salon skorelowana z Devices o nazwie pic32 reprezentowała czujnik temperatury w fizycznym urządzeniu, dlatego najbardziej adekwatnym widgetem jest widget opisany jako Thermometr i taką ikonkę wybieramy klikając w nią. Pokaże się widok jak poniżej :

W powyższym widoku "klikamy" Add Variables, pojawi się okienko ze spisem naszych Devices , mamy tylko jedno o nazwie pic32 , "klikamy" w nie , pojawi się spis Variables przyporządkowanych do naszego Devices, mamy tylko jedno opisane jako Temperatura Salon, wybieramy je i zatwierdzamy zielonym  "ptaszkiem" :

Po zatwierdzeniu przejdziemy do widoku jak poniżej . Zapomniałem podać nazwę widgetu , w tym celu w polu Name podałem Temperatura Salon . Następnie zatwierdzamy zielonym "ptaszkiem".

W efekcie na naszej tablicy pojawi się nowy element jak poniżej w którym nie ma danych bo jeszcze ich nie przesłaliśmy do chmury.

Wspomnę , że każdy element łącznie z tablicą można "customizować" , zmieniać kolorystykę etc.

No dobrze tę nudniejszą część zabawy mamy za sobą teraz czas na przesłanie danej do naszego Widgetu przy pomocy duetu PIC32MM + W5500.  W tym wypadku musimy zajrzeć do dokumentacji chmury. Na głównej stronie Ubidots wybieramy zakładkę Resources a w niej API Docs :

Dokumentacja występuje w dwóch wariantach Hardware Engineers i Software Engineers. Widać , że w chmurze pracują ludzie , którzy sami byli kiedyś po drugiej stronie ekranu czyli nie w chmurze tylko po stronie użytkownika :). Wybieramy zatem opcję dla sprzętowców i tam docieramy do dokumentacji API chmury.


Już na samym początku dokumentacji dowiadujemy się, że mamy do dyspozycji trzy metody dostępu do chmury : HTTP, MQTT, TCP/UDP. Ja w tym wpisie zajmę się pierwszym z nich czyli HTTP . Na bazie protokołu HTTP programiści "wysokopoziomowi" dorobili swoją "filozofię" w postaci API REST a to nic innego jak metody HTTP obudowane "filozofią". Do celem dla moich działań z modułem W5500 jest uruchomienie komunikacji za pomocą MQTT ,ponieważ jest to protokół idealnie skrojony na miarę urządzeń IoT. Aczkolwiek bardzo ciekawie wygląda rozmowa z chmurą za pomocą samego protokołu TCP/UDP , nie posługujemy się w tym przypadku żadnymi nagłówkami HTTP i nie odbieramy miliona nagłówków w odpowiedzi ale prosta sekwencja danych w jedną i drugą stronę.

W dokumentacji API chmury szukamy wzorca jakim trzeba się fizycznie posłużyć aby skomunikować się z chmurą. Potrzebujemy wzorca dla ustawienia zmiennej Variables  w chmurze i dla odczytania jej wartości. Na początek to wystarczy w zabawach z chmurą.

W/g dokumentacji możemy odwoływać się do urządzenia Devices lub do konkretnej zmiennej Variables . Odwołując się do urządzenia możemy zmieniać lub odczytywać wiele zmiennych na raz skorelowanych z Devices. Odwołując się do Variables rozmawiamy tylko z konkretną jedną zmienną.

Zobaczymy jak wygląda odwołanie do urządzenia Devices , nasze urządzenie w chmurze nazwałem pic32.

Wzorzec do zmiany wartości zmiennej w chmurze za pomocą odwołania do urządzenia Devices wygląda w dokumentacji jak poniżej :

Interesuje nas to co jest po lewej stronie . W polach czarnych mamy strukturę wysyłanej wiadomości za pomocą Linuxowego programu curl. Nas to nie interesuje tutaj. Zróbmy retrospektywę zapisu wysyłanej wiadomości do chmury za pomocą protokołu HTTP i wykorzystując API REST.  Pierwszy wiersz / nagłówek zgodnie z instrukcją ma postać :

POST /api/v1.6/devices/{DEVICE_LABEL} HTTP/1.1<CR><LN>

Metoda HTTP - POST, informuje serwer (chmurę), że po swojej stronie będzie musiał/musiała dokonać zmiany , zmienić wartość czegoś , na tym etapie serwer jeszcze nie wie czego :). W miejsce Device_Label musimy wpisać nazwę naszego urządzenia czyli pic32. Zatem postać pierwszego wiersza naszej wiadomości HTTP będzie wyglądać jak poniżej :

POST /api/v1.6/devices/pic32 HTTP/1.1<CR><LN>

Przechodzimy do drugiego wiersza 

Host: {Host}<CR><LN>

W tym wierszu podajemy nazwę hosta czyli adres naszej chmury dla komunikacji po HTTP. W naszym przypadku będzie to : industrial.api.ubidots.com. Tę informację oczywiście zdobywamy z dokumentacji. Nasz zapis w drugim wierszu będzie zatem wyglądał tak :

Host: industrial.api.ubidots.com<CR><LN>

Przechodzimy do analizy trzeciego wiersza :

User-Agent: {USER_AGENT}<CR><LN>

Tutaj jest dobra wiadomość , nie jest to wymagany nagłówek w protokole HTTP więc i nasza chmura bez tej danej powinna się obejść. Zatem pomijam ten wiersz całkowicie i nie będę go wysyłał. Tutaj z grubsza trzeba by było podać dane wrażliwe na RODO :)

Przechodzimy do kolejnego wiersza :

X-Auth-Token: {TOKEN}<CR><LN>

W powyższym wierszu musimy podać TOKEN , bez którego nie dostaniemy się do chmury. Jest to forma autoryzacji. Ale skąd ten Token wziąć. Aby go uzyskać musimy zalogować się na nasze konto w Ubidots i wejść w My Profile :

i potem wybrać API keys i tam zaznaczyłem co jest naszym Tokenem :

To , że pokazuję swoje Tokeny nie stanowi dla mnie problemu bo potem wygeneruję  sobie  nowy tokeny :). Kopiuję zatem ciąg Token-u i nasz wiersz będzie wyglądał jak poniżej :

X-Auth-Token: BBFF-dlkCOCzYMfLY9AV5wgxgsDrP2brXYZ<CR><LN>

Analizujemy kolejny wiersz z dokumentacji :

Content-Type: application/json<CR><LN>

W tym wierszu informujemy serwer w jakim formacie opakujemy mu przesłane dane. Docelowym formatem w chmurze jest json. Nasza dana czyli wartość jaką chcemy przesłać do Variables o nazwie temperaturasalon może w formacie json wyglądać np. tak :

{"temperaturasalon": 19.5}

Nasz analizowany wiersz przepisany zostanie kropka w kropkę i wygląda tak :

Content-Type: application/json<CR><LN>

Kolejny wiersz : 

Content-Length: {PAYLOAD_LENGTH}<CR><LN><CR><LN>

W powyższym wierszu musimy podać długość znaków w naszej przesyłanej danej
{"temperaturasalon": 19.5}. Liczymy na piechotę na razie, mnie wyszło 26 w tym jedna spacja i nawiasy. Nasz wiersz nagłówkowy będzie zatem wyglądał jak poniżej :

Content-Length: 26<CR><LN><CR><LN>

Nie wspominałem o tym ale te wszystkie znaki przełamania linii mają w nagłówkach HTTP kluczowe znaczenie, nie można ani jednego pominąć. Zbliżamy się powoli do końca . Kolejny wiersz :

{PAYLOAD}

To najważniejszy nagłówek z naszego punktu widzenia bo to będzie odwołanie do naszej zmiennej Variables i podania jej wartości np :

{"temperaturasalon": 19.5} 

Na końcu ostatni wiersz to przełamanie linii 

<CR><LN>

Podsumujmy zatem jak będzie prezentował się nasz tekst zapytania HTTP do serwera w chmurze Ubidots, który zmieni nam wartość zmiennej Variables o nazwie temperaturasalon na wartość 19.5 w urządzeniu Devices o nazwie pic32 :

POST /api/v1.6/devices/pic32 HTTP/1.1<CR><LN>
Host: industrial.api.ubidots.com<CR><LN>
X-Auth-Token: BBFF-dlkCOCzYMfLY9AV5wgxgsDrP2brXYZ<CR><LN>
Content-Type: application/json<CR><LN>
Content-Length: 26<CR><LN><CR><LN>
{"temperaturasalon": 19.5}
<CR><LN>


Powyższy ciąg znaków musimy przesłać do chmury. W zapytaniu możemy przesyłać wiele zmiennych na raz. W dokumentacji jest podana treść odpowiedzi jaką prześle nam serwer chmury na nasze zapytanie HTTP. Jej struktura wygląda jak poniżej :

Expected Response:

HTTP/1.1 200 OK<CR><LN>
Server: nginx<CR><LN>
Date: Tue, 04 Sep 2018 22:35:06 GMT<CR><LN>
Content-Type: application/json<CR><LN>
Transfer-Encoding: chunked<CR><LN>
Vary: Cookie<CR><LN>
Allow: GET, POST, HEAD, OPTIONS<CR><LN><CR><LN>
{PAYLOAD_LENGTH_IN_HEXADECIMAL}<CR><LN>
{"{VARIABLE_LABEL}": [{"status_code": 201}]}<CR><LN>0<CR><LN>

Dla nas istotne w tej odpowiedzi jest tylko to czy status code ma wartość 201 jeśli tak to wszystko jest oki i serwer pozytywnie przetworzył nasze zapytanie HTTP. Czyli w programie teoretycznie powinniśmy wyłowić z treści odpowiedzi tę daną. Chociaż w uproszczeniu wystarczy nam kod 200 na początku nagłówka HTTP, prościej będzie go wyłowić w kodzie.

Zostawiamy na razie w spokoju dokumentację chmury i próbujemy to ogarnąć od strony modułu W5500. Aby nawiązać połączenie z chmura po TCP/IP musimy znać jej adres IP i port . Adres IP konkretnie tego ciągu :

industrial.api.ubidots.com ma postać : 169.55.61.243 . Skąd to wiem ? a po prostu komenda ping z konsoli linuxa z nazwą  i otrzymałem zwrotnie informację o adresie IP adresata . Numer portu mamy w dokumentacji dla http jest to 80 a dla https 443, my wybieramy port nr 80.

W sumie teraz trzeba nasz zamiar komunikacji z chmurą opakować w kod  w MPLABX-IDE. Ale po drodze mam małą niespodziankę , padł mi dysk SSD w kompie, zamówiłem nowy ,bez tego dalej nie ruszę :)

Dysk już mam. Potęga Linuxa i chmury :). Linuxa ze wszystkimi sterownikami w pakiecie postawiłem w mniej niż 10 minut, dane przetrzymuję w chmurze czyli projekty i ważniejsze pliki ,więc w każdej chwili mam do nich dostęp z dowolnego kompa. Aż nie chce mi się myśleć ile czasu bym zmarnował na postawienie Windy ze sterownikami a do tego jeszcze Office i inne pierdoły , które w Linuxie są od razu po instalacji systemu. 

W międzyczasie miałem jeszcze gości z Grecji , zwiedzali Kraków i Warszawę , ugościłem ich po Staropolsku czyli tak, że nie chcieli wracać do swojego kraju :). Byli zachwyceni Polską, Polakami i wszystkim tym co tutaj widzieli. Najbardziej smakowały im nasze kiełbasy ,  bigos i szarlotka :)

No dobrze nie przynudzam i wracam do kontynuacji tematu . Pod kątem tego artykułu napisałem krótki program do testowania wysyłania danych do chmury .

W dalszej części skupię się na opisaniu poszczególnych funkcjonalności w programie służącym wysyłaniu danych do chmury. Pokażę jak opakować zapytanie do chmury w języku C oraz jak dodać do zapytania zmienną numeryczną . Wszystko będzie proste . W5500 działa doskonale nie napotkałem jeszcze jak na razie na żadne problemy zarówno w komunikacji jak i stabilności działania modułu. Ciekawe jak chińskie moduły tutaj się zaprezentują , na razie nie mam z nimi doświadczenia, działam na oryginale z firmy Mikroelektronika.

Chmura Ubidots rewelacyjnie współpracuje z modułem. Żałuję , że wcześniej nie zająłem się tą tematyką tylko krążyłem wokół pierduł .

Najpierw napiszę o ogólnej funkcjonalności programu czyli co robi program ?.
W programie otwieramy połączenie TCP/IP z chmurą Ubidots a następnie przesyłamy do niej a konkretnie do danej temperaturasalon co 5 sekund zawartość zmiennej licznik , która przyjmuje wartości od 1 do 10. Po stronie chmury zobaczymy zmianę wartości w polu Temperatura Salon . Na UART będą wyrzucane komunikaty związane z procesem wysyłania danych przez W5500 i odpowiedzi serwera w chmurze. Będziemy mogli podejrzeć jak wygląda fizycznie odpowiedź serwera na wysłany przez nas komunikat . Zabawa jest przednia.

Pętla główna programu wykonuje jedną tylko funkcję TCP_HTTP(), funkcja ta realizuje całą funkcjonalność programu czyli otwiera gniazdo TCP po stronie modułu W5500, nawiązuje połączenie z chmurą i wysyła do niej treść naszego zapytania  oraz odbiera zwrotnie komunikat serwera "chmurowego".

Zaglądamy do środka funkcji TCP_HTTP() a wszczególności do początku tej funkcji (poniższy obrazek nie wyczerpuje zawartości całej funkcji):

Na początku powłujemy sobie bufor POST_Ubidots[] i zmienną ile. W buforze będziemy docelowo umieszczać całego stringa stanowiącego nasze zapytanie do chmury. Zmienna pomocnicza ile będzie przechowywać długość fragmentu  stringa w którym odwołujemy się do zmiennej temperaturasalon, konkretnie chodzi o ten fragment zapytania : {"temperaturasalon": 19.5}. Musimy określić długość tego fragmentu i wstawić tę daną do głównego zapytania HTTP. Aby wstawić daną numeryczną do stringa posługuję się funkcją biblioteczną języka C sprintf().

Fizyczna postać stringa wysyłanego do chmury jest pakowana do tablicy POST_Ubidots[], widzimy to w zaznaczonym poniżej fragmencie :

Tu zwracam uwagę  , że każda linia jest przełamana znakiem specjalnym \, ten znak nie jest uwzględniany w wysyłanym stringu. Znak specjalny również pojawia się np. przed wysyłanymi cudzysłowami. Bez tego znaku nie zapiszemy poprawnie do tablicy naszego stringa.

Funkcja sprintf() uwzględnia nam w budowie naszego stringa dane numeryczne ile i naszą daną zmieniającą się od 1 do 10 - licznik.

Poniżej fragment naszej funkcji, w którym jest realizowana fizycznie wysyłka stringa z tablicy POST_Ubidots[] do chmury co 5 sekund.

Do obsługi czasu powołałem timer programowy SoftTimer1 popędzany  timerem sprzętowym TMR1. Co 5 sekund zostanie spełniony warunek, po czym najpierw wysyłana jest  na UART zawartość bufora POST_Ubidots[], czyli to co wysyłamy do chmury. Potem za pomocą funkcji bibliotecznej send() modułu W5500 wysyłamy fizycznie zawartość bufora do chmury. Aby wysyłka mogła nastąpić najpierw musi zostać otwarte gniazdo po stronie modułu W5500 a potem ustanowione połączenie TCP z chmurą. Otwarcie gniazda realizuje nam poniższy fragment programu :

gdzie SOCK_ID_TCP = 0 to nasz numer gniazda, Sn_MR_TCP - argument informujący funkcję socket(), że nasze gniazdo będzie TCP, oraz PORT_TCP = 5000

Po otwarciu gniazda przechodzimy do ustanowienia połączenia z chmurą, realizuje nam to poniższy fragment programu :

Do funkcji connect() , musimy podać trzy argumenty , numer gniazda w naszym przypadku 0 (W5500 ma do dyspozycji gniazda od 0 do 7), adres IP chmury Ubidots - 169.55.61.243 i port gniazda chmury numer 80.

Efekt działania programu na poniższych zdjęciach :

Po lewej stronie na zdjęciu mamy obraz z chmury Ubidots czyli nasz Dashboard i okienko Temperatura Salon reprezentujące naszą zmienną temperaturasalon. Po prawej mamy komunikaty jakie wyrzuca po UART program. Na początku nie miałem podłączonego kabla do W5500, dlatego widzimy komunikaty typu Unknown PHY Link status. Po wpięciu kabla RJ45 łączącego Router LTE z modułem W5500 moduł zostaje w pełni zainicjalizowany i pojawiają się parametry sieciowe takie jak MAC , IP  modułu etc. Następnie zostaje otwarte gniazdo nr 0 po stronie modułu i nawiązane połączenie z chmurą. Potem wysyłana jest formatka zapytania HTTP metodą POST a w niej na końcu nasza dana temperaturasalon z wartością 1. Po wysyłaniu naszego zapytania do chmury otrzymujemy od serwera "chmurowego"  ładną i zgrabną odpowiedź zaczynającą się od HTTP /1.1 200 OK. Po 5 sekundach formowany jest obraz nowego zapytania z inną wartością zmiennej . Na drugim obrazku widzimy już , że przesłana wartość zmiennej to 2. Potem kolejno zmienna przyjmie wartość 3...10 i po tym od początku 1...10 i tak w koło Macieju.

Tutaj drobna uwaga. My przesyłamy do chmury wielkości całkowite (dla uproszczenia) a w chmurze widzimy po przecinku, czyli my wysyłamy 1 a chmura wyświetla wartość 1.0. Format po przecinku od strony chmury został wymuszony przeze mnie w ustawieniach pola Temperatura Salon. Czyli defakto przygotowałem chmurę do odbioru danych z jedną cyfrą po przecinku, pomimo, że nie wysyłamy w tym formacie danych , chmura je konwertuje do tego co ona ma ustawione.

Jeśli w programie naszym chcemy wysyłać zmienną z jednym znakiem po przecinku to w ciągu tekstowym funkcji sprintf() musimy się posłużyć zapisem %.1f

Umiemy zatem wysyłać dane do chmury. Zapomniałem wspomnieć o aplikacji mobilnej , jeśli chcemy zobaczyć jak zmienia się nasza dana w chmurze za pomocą telefonu to należy zainstalować aplikację Ubidots na telefon i zalogować się do konta w chmurze.

Sam byłem zaskoczony, że przesyłanie danych do chmury za pomocą modułu W5500 tak świetnie działa. W kolejnym artykule zajmiemy się odbieraniem danej z chmury. Ale najlepsze dalej przed nami czyli komunikacja MQTT, która w mojej ocenie jest jedynym słusznym wyborem w zakresie wymiany danych z chmurą przez urządzenie IoT oparte o MCU i moduł W5500.

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/PICmajste/PIC32MM_W5500_Send_HTTP.git

Pozdrawiam
picmajster.blog@gmail.com

Linki:

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