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.
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.
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.
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
picmajster.blog@gmail.com
Linki:
Chmura Ubidots - dokumentacja
Program na GitHub- Send data to Ubidots
genialny artykuł
OdpowiedzUsuńDziękuję. Cieszę się,że ktoś to czyta :)
OdpowiedzUsuń