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

Kontynuujemy przygodę z modułem ethernetowym W5500 i PIC32MM oraz chmurą Ubidots. W części nr 3 artykułu  pokazałem metodę komunikacji z chmurą opartą o protokół HTTP i metodę POST. Wysyłaliśmy z powodzeniem daną do chmury.  Wspomniałem, że pokażę jak się tą metodą odbiera dane. Kiedy podczas testów odbierania danej z chmury zobaczyłem ile nadmiarowych informacji musimy odebrać aby dobrać się do naszej danej , doszedłem do wniosku , że nie będzie to preferowana metoda komunikacji z chmurą dla zestawu MCU + W5500. Dlatego nie będę tego wątku kontynuował. Chmura Ubidots ma tę ogromną zaletę, że dostarcza różnych metod przesyłania danych do wyboru, jedną z nich jest bardzo prosta metoda oparta na samym protokole TCP lub  UDP i zapytaniach znakowych . Od strony chmury w warstwie aplikacji, tego typu prosta komunikacja obsługiwana jest przez protokół Telnet , stworzony dla terminali znakowych. Telnet jest najstarszą i najbardziej elementarną usługą internetową , która dzisiaj została wyparta przez protokół SSH. Ekosystem internetu i usług sieciowych opiera się na ogromnej liczbie protokołów. W artykule pokażę jak posłużyć się bardzo prostą metodą komunikacji z chmurą. Nie będzie żadnych nadmiarowych komunikatów tak jak w przypadku protokołu HTTP.

Część sprzętowa pozostaje bez zmian tak jak zaczęliśmy wątek o PIC32MM i W5500. Program z części nr 3 będzie wymagał jedynie subtelnych zmian. Najpierw zerknijmy do dokumentacji chmury Ubidots w zakresie przesyłania komunikatów TCP. Na początek bardzo ważna uwaga. O ile do nawiązania komunikacji z chmurą Ubidots w przypadku protokołu HTTP posługiwaliśmy się portem nr. 80 o tyle dla połączenia TCP lub UDP musimy posłużyć się portem nr. 9012. Wyczytamy to z dokumentacji chmury.

Poniżej obraz jak wygląda strumień znakowy wysyłany do chmury ,który ustawi w urządzeniu o nazwie pic32 zmienną o nazwie temperaturasalon na wartość 19.5 (oczywiście urządzenie pic32 i zmienna temperaturasalon, muszą być uprzednio w chmurze Ubidots powołane do życia) :

Dom/1.0|POST|TOKEN|pic32=>temperaturasalon:19.5|end

jeśli chcemy ustawić więcej niż jedną zmienną w urządzeniu o nazwie pic32 to użyjemy zapisu jak poniżej :

Dom/1.0|POST|TOKEN|pic32=>temperaturasalon:19.5,temperaturakuchnia:18.3|end

Gdzie za TOKEN musimy podstawić swój token z chmury, pokazywałem gdzie tego szukać w innym artykule.

W zapisach widzimy słowo POST ale to nie jest metoda HTTP w tym przypadku.

Fragment Dom/1.0 to tzw i tu posłużę się wycinkiem z dokumentacji : {USER_AGENT}: Mandatory. Contains a characteristic string that allows to identify the application type, operating system, software vendor or software version of the requesting software user agent. Examples: ESP8266/1.0, Particle/1.2

Obojętnie co tu wpiszemy,  coś tu musi być wpisane i tyle :)

Widzimy , że zapis wysyłający do chmury wartość zmiennej jest bardzo prosty, już prościej chyba się nie da i mega prostszy w stosunku do nagłówków HTTP, nie musimy tutaj informować serwera ile znaków danych będziemy przesyłać i w jakim formacie będziemy to robić. Mamy jeden ustalony wzorzec znakowy i tyle w temacie. Niech żyje prostota. To nie znaczy , że HTTP w ogóle jest do bani , bo tak nie jest, jest to podstawa komunikacji w internecie. Ale jest to protokół przyjazny językom wysokopoziomowym takim jak Java, Python, JavaScript etc. W przypadku urządzeń IoT w których nie ma zaimplementowanych języków wysokopoziomowych nie jest to optymalne rozwiązanie, tutaj najlepiej dopasowanym w zakresie komunikacji jest protokół MQTT, stworzony przez pracownika firmy IBM. Ale o tym w innym artykule napiszę.

Jeśli wysłanie danych do chmury się powiedzie, otrzymamy zwrotnie prosty komunikat typu OK lub gdy się nie powiedzie ERROR. No bajka.

Zerknijmy teraz jak będzie wyglądało zapytanie o daną temperaturasalon w urządzeniu o nazwie pic32.

Dom/1.0|LV|TOKEN|pic32:temperaturasalon|end

a pytanie o np. dwie zmienne temperaturasalon i temperaturakuchnia ma postać :

Dom/1.0|LV|TOKEN|pic32:temperaturasalon,temperaturakuchnia|end

W odpowiedzi z chmury otrzymamy bardzo prosty komunikat np jak poniżej dla jednej zmiennej :

OK|19.5

W zasadzie wyczerpaliśmy temat, teraz trzeba sprawdzić czy to działa na żywym organizmie . Wykorzystam program z części nr 3 . Tak samo będziemy wysyłać cyklicznie co 5 sekund do zmiennej w chmurze temperaturasalon zawartość zmiennej licznik w programie, która będzie się zmieniać od 1 do 10. A następnie będziemy pytać chmurę o zawartość danej temperaturasalon , odpowiedź zobaczymy na terminalu UART.

Nie mogę się doczekać efektów zabawy a wiem , że będą fajne :). W zasadzie mając do dyspozycji tak łatwy protokół komunikacji z chmurą już można się bawić w automatykę domową .

Poniżej pokażę różnicę w stosunku do programu z części nr 3 gdzie wysyłaliśmy do chmury dane metodą POST HTTP.

W tablicy GET_POST[] znajduje się obraz zapytania o daną temperaturasalon. A w tablicy POST_Ubidots[], tworzymy obraz zapytania zmieniającego zmienną temperaturasalon (w chmurze) , przekazujemy do niej wartość zmiennej licznik (w programie), zmienna licznik co 5 sekund zmienia swoją wartość w zakresie 1...10.

Poniżej fragment programu wysyłający do chmury dwa powyższe zapytania.

Efekt pracy programu poniżej , najpierw brak podłączenia kablem RJ45 , modułu W5500 do Routera LTE :

Podłączamy kabel i jedziemy :

Najpierw wysyłane są dwa zapytania jedno po drugim bez zwłoki czasowej.  Pierwsze leci zapytanie ustawiające w chmurze daną temperaturasalon na wartość 1. A potem leci do chmury zapytanie o wartość danej temperaturasalon. Chmura odpowiada OK na pierwsze zapytanie i powinna odpowiedzieć OK|1 na drugie. Następnie za 5 sek leci do chmury ponownie sekwencja zapytań jedno po drugim, zapytanie w którym ustawiliśmy wartość zmiennej temperaturasalon na 2. Odpowiedź chmury OK i OK|2. I tak w koło Macieju.

Program może nie jest szczytem doskonalości bo tak nie jest, na pewno szczegóły by trzeba było dopracować i np. uzależnić wysłanie zapytania o wartość zmiennej w chmurze od otrzymania komunkatu OK po ustawieniu danej na inną wartość. Bo możemy natknąć się na przypadek kiedy zmienna nie została jeszcze ustawiona w chmurze na nową wartość i wtedy odczytamy jej poprzednią wartość. Nie mniej to co chciałem pokazać czyli  sposób wysyłania zapytań TCP za pomocą modułu W5500 pokazałem i to działa, reszta to już szlify doskonalące i własne wariacje na temat.

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_Ubidots.git

Pozdrawiam
picmajster.blog@gmail.com

Linki:

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