IoT naprave v globalnem AWS oblaku – 4. del

Raspberry Pi odličen za testiranje PIC-IoT
V preteklih nadaljevanjih smo veliko povedali o Microchipovih AWS razvojnih ploščah, med katerimi smo omenili tudi PIC-IoT in AVR-IoT, ki omogočata hiter preizkus in predstavitev uporabe AWS IoT in AWS Lambda storitev s PIC in AVR mikrokontrolerji. Znanje programiranja pri tem ni potrebno, prav tako se nam ni potrebno registrirati in prijaviti v AWS konzolo, saj so pri Microchipu na osnovi AWS storitev pripravili celovito aplikacijo, v katero so po modelu Greengrass vnaprej vključili vse PIC-IoT, AVR-IoT in SAM-IoT Curiosity razvojne plošče.

V navodilih za uporabo razvojnih plošč zasledimo zahtevo za odprtje določenih TCP/IP vrat, ki omogočajo prenos podatkov MQTT. Vseeno pa je najenostavneje in najhitreje za testiranje razvojne plošče s prednaloženo vgrajeno programsko opremo izbrati kar računalnik, ki za delo z Internetom ne potrebuje vklopljenega požarnega zidu, saj bi bila morebitna škoda, ki bi jo lahko povzročila morebitna zlonamerna programska oprema prek spleta, zanemarljiva.
Zanimalo me je, če bo PIC-IoT deloval tudi na Raspbery Pi 3. In res, vse je delovalo brezhibno, pri čemer je prednost Raspberry Pi 3 predvsem v tem, da kot pogon za masovno hrambo uporablja SD kartico in nima kakega zapletenega BIOS-a. Če bi šlo karkoli narobe, bi vanj enostavno vstavil drugo SD kartico s svežo kopijo operacijskega sistema in osnovne programske opreme. Morda ni odveč omeniti, da lahko pri Raspberry Pi 4 nadgrajujemo tudi v mikrokontroler vgrajeno programsko opremo, zato je to morda dodatni faktor tveganja.
Kot lahko razberete in vidite iz posnetkov zaslonov v nadaljevanju, pa se je Razberry Pi 3 kot gostitelj PIC-IoT razvojne plošče vseeno odlično obnesel. Kljub temu, da lahko MPLAB X IDE zaenkrat poganjamo le na računalnikih z Intelovimi in AMDjevimi procesorji, pa je za Rasberry Pi na voljo podpora za oddaljeno razhroščevanje in programiranje Microchipovih mikrokontrolerjev z Microchip PICkit 4 in Microchip Snap. Tako razhroščevalnik/programator sicer lahko priklopimo na Raspberry Pi, pri čemer MPLAB X poganjamo na PCju. Lahko pa vseeno poskusite na Raspberry Pi 4 zagnati MPLAX X IDE v posnemovalniku PC…

Kako deluje PIC-IoT?
Posebnost PIC-IoT razvojne plošče je programator in USB/RS-232 most, ki je izdelan na osnovi SAMD21E mikrokontrolerja, in ne s PIC mikrokontrolerjem. Razlog za to je skoraj gotovo v podobnosti trojčka Microchipovih razvojnih plošč: AVR-IoT, PIC-IoT in SAM-IoT, ki se medsebojno razlikujejo le uporabljenem glavnem mikrokontrolerju in jih uporabljamo v Amazonovem (AWS), Googlovem (Google Cloud), Microsoftovem (Azure) ali drugem računalniškem oblaku. Prva ima ATMEGA4808, druga PIC24FJ128GA in tretja SAM21DG glavni mikrokontroler. Kljub temu vse programira isti vgrajeni SAMD21E mikrokontroler (programator), ki je poleg napajalnika/polnilnika in WINC1510 WiFi modula četrti najpomembnejši element za zagotavljanje njihovega delovanja.

Razvojna plošča se s pomočjo USB/RS-232 mostu (v SAMD21E) PC predstavi kot navidezna zaporedna vrata (COMx na PC in /dev/ttyACMx na Raspberry Pi) in podatkovni pogon, na katerem so prednaložene ključne datoteke, ki omogočajo dostop do Microchipove testne AWS spletne strani, ki jo odpremo z dvoklikom na CLICK-ME.HTM. Pri odpiranju te strani mora biti gostiteljski PC povezan v Internet.
Za povezavo z oblakom potrebujemo tudi Wi-Fi dostopno točko, katere SSID in geslo moramo vpisati v razvojno ploščo, kar lahko naredimo na dva načina: s kopiranjem WIFI.CFG datoteke na podatkovni pogon razvojne plošče, z direktnim vnosom poverilnic prek USB/RS-232 mostu. Čeprav je prvi način enostavnejši, a žal v navodilih za uporabo PIC-IoT ali AVR-IoT razvojne plošče ne najdemo opisa zgradbe te tekstovne datoteka. Najdemo le navodilo, da lahko datoteko izdelamo s pomočjo Microchipove spletne strani, do katere pridemo s klikom na CLICK-ME.HTM; kar sem tudi storil.

Pri Microchipu vseskozi poudarjajo pomen spletne varnosti. Zato je v navodilih omenjeno, da se SSID in geslo naše Wi-Fi dostopne točke ne shranita na spletni strežnik, temveč le v datoteko WIFI.CFG na našem računalniku. Dodajmo le, da je pri tem dobro paziti, da morebiti SSID in gesla v piškotkih ne shrani spletni brskalnik. Navajajo tudi, da datoteka WIFI.CFG izgine iz podatkovnega pogona razvojne plošče, takoj ko jo prenesemo. Čeprav je mogoče, da jo operacijskih sistem našega računalnika še nekaj časa hrani v začasnem medpomnilniku pogona in jo bomo zato še nekaj časa videli, je zagotovo ne bo več, če razvojno ploščo odklopimo in ponovno priklopimo. Kljub temu se poverilnice trajno shranijo v razvojno ploščo, zato se bo naslednjič samodejno povezala z našo dostopno točko.
Prenos podatkov potrebujemo še javni ključ, s katerim dostopamo do Microchipove testne strani, in identifikacijsko številko razvojne plošče, ki jo uporabljamo. Oba podatka sta prednaložena na razvojno ploščo. Tako lahko Microchipova spletna aplikacija prikaže trenutno osvetlitev in temperaturo, ki ji zaznava naša razvojna plošča.

Morda v zvezi z navedenim predstavimo še preprost trik, s katerim pri sestavljanju datoteke WIFI.CFG zaobidemo vnos poverilnic dostopne točke v Microchipovo spletno stran. V slednjo lahko, na primer za SSID in geslo vnesemo kar »TEST1« in »TEST2«, s čemer dobimo vzorčno datoteko WIFI.CFG, ki je v lahko razumljivi tekstovni obliki. Nato besedili TEST1 in TEST2 v enostavnem tekstovnem urejevalniku (npr. NOTEPAD, NANO ipd., odvisno od operacijskega sistema) zamenjamo z dejanskima SSID in geslom. Tako dobimo datoteko, ki jo lahko prenesemo v razvojno ploščo, ne da bi prej posredovali v internet svoje poverilnice. Za ostale povejmo, da je za vnos SSID in gesla potrebno v datoteko vnesti le eno besedilno vrstico: CMD_SEND_UART=wifi <SSID>,<geslo>,<WIFI kriptografski protokol>. Denimo: CMD_SEND_UART=wifi TEST1,TEST2,2. Z 2 označimo WAP2 kriptografski protokol.
Drugi način povezave z WiFi dostopno točko je prek USB/RS-232 vmesnika oz. tekstovne terminalske povezave. Pomoč je na voljo, če v terminalsko okno vtipkamo »help«. Izvesti moramo ukaz »wifi <SSID>,<geslo>,<WIFI kriptografski protokol>«, kar je pravzaprav skoraj enako kot smo navedli v datoteki WiFi.CFG, le da smo tam na začetek dodali še »CMD:SENT_UART=«. Glede terminalskega vmesnika povejmo še, da ne vrača kod pritisnjenih znakov, zato ne vemo, kaj tipkamo, razen če tako možnost lahko nastavimo v terminalskem programu v osebnem računalniku.
V izogib morebitnim težavam pri vnosu (pre)dolgih SSID in gesel omenimo še to, da sta najdaljša mogoča SSID in geslo pri PIC-IoT omejena na 19 znakov; kar pa ni splošna praksa, saj v večino drugih naprav lahko vnesemo tudi več kot dvakrat daljša gesla, medtem ko mora biti SSID krajši.

Demonstracija prenosa in vizualizacije podatkov
PIC-IoT razvojna plošča ima ob strani nameščene 4 raznobarvne svetleče diode (modro, zeleno, rumeno in rdečo), ki prikazujejo status povezave z AWS oblakom in pretok podatkov. Ko razvojna plošča vzpostavi povezavo z WiFi dostopno točko, modra LED preneha utripati, medtem ko zelena LED utripa dokler ni vzpostavljena povezava z AWS oblakom. Rumena LED utripa med uspešno objavo MQTT sporočila, medtem ko se rdeča LED prižge le izjemoma, če pride v Microchipovi oblačni aplikaciji , med obdelavo podatkov iz razvojne plošče do napake.

Vizualizacija podatkov na osebnem računalniku je mogoča tudi na oddaljenih lokacijah. Pomembno je le, da vsebino podatkovnega pogona razvojne plošče prenesemo na ciljni PC in dvokliknemo na CLICK-ME.HTM datoteko, s čemer odpremo spletno stran s podatki naše PIC-IoT razvojne ploščice. Spletna stran samodejno zaznava tekoč prenos podatkov o osvetlitvi in temperaturi, s katerimi sproti osvežuje grafa. Ko razvojno ploščico odklopimo, javi napako, ki jo grafa nadomestita takoj, ko kartico spet priklopimo.

Vzorčni projekt PIC-IoT in razvojno okolje
Morda opisani prikaz delovanja PIC-IoT daje vtis, da nam za prenos in vizualizacijo podatkov v lastni aplikaciji na osnovi AWS storitev ni potrebno kaj dosti storiti, a ni tako. Predlagam, da pred začetkom pisanja lastne programske kode zato preletite pretekla nadaljevanja, kjer boste prebrali o postopku registracije za uporabo AWS, storitev, njihovem delovanji in implementaciji različnih rešitev pa tudi primere enostavnih rešitev, kot je razpoznavanje s ESP32-CAM zajetih slik.
Ko se lotevamo lastne aplikacije, moramo misliti, ne le na programiranje IoT razvojne ploščice, temveč tudi na pripravo zaledne aplikacije v računalniškem oblaku.

Osnovno okolje za razvoj PIC-IoT (za PIC24) ugnezdene programske opreme je Microchip MPLAB X z Microchip Code Configurator vtičnikom (MCC). Najlažje ga namestimo na računalnik s stalno internetno povezavo, saj MCC v tem primeru samodejno namesti vse potrebne knjižnice. Za tiste, ki bi se nameščanja slednjih morebiti lotili ročno povejmo, da je potrebno namestiti natančno tiste različice knjižnic, ki so navedene v projektni MC3 datoteki. Če naložimo druge različice, MCC le redko ponudi alternativno izbiro, pa še to z našim privoljenjem. Ustreznost knjižnic lahko vidimo tudi v spodnjem levem kotu namizja MCC, ko odpremo zavihek Versions, v katerem lahko v drevesnem pregledu vidimo ustreznost vsake od MCC knjižnic.
Za uspešno konfiguriranje in prevajane vzorčnega projekta moramo namestiti naslednje razvojno okolje: MPLAB X 5.15 ali novejši, XC16 Compiler v1.35 ali novejši, MCC Plug-in v3.75 ali novejši, MCC Foundation Services v 0.1.32 ali novejši in MCC PIC-IoT WG Sensor Node v1.1.1 ali novejši.
Morda povejmo še to, da MCC knjižnice podajajo strukturo naprave in njenih komponent, tako ga lahko določene lastnosti urejamo grafično, obenem pa še te po pritisku na tipko Generate, s pomočjo vgrajenega generatorja programske kode vgradijo v izvorno kodo vgrajen programske opreme. Pri tem imamo, kot smo že vajeni, tudi možnost odobritve ali zavrnitve (posameznih) sprememb, ki jih predlaga programski generator v vsaki od programskih datotek. Vsekakor pa imamo z grafičnim urejanjem lastnost boljši pregled in vpogled v delovanje ugnezdene programske kode naprav.
AVR-IoT, SAM-IoT in PIC-IoT razvojne ploščice lahko vključimo v različne računalniške oblake. Vendar bomo storitve Google Cloud in Microsoft Azur računalniških oblakov zaradi obsežnosti raje predstavili v posebnem članku. Zaenkrat prav tako ostanemo tudi pri PIC-IoT razvojni ploščici s PIC24 glavnim mikrokontrolerjem.

Drugi primeri v spletu
PIC-IoT počasi odkrivajo tudi samostojni razvijalci programske kode. Večina projektov je na tak ali drugačen način povezanih z računalniškimi oblaki, pri čemer je poleg AWS v ospredju tudi Google Cloud. Razvojni projekti s pridom izkoriščajo razširitveni priključek PIC-IoT razvojne plošče, prek katerega je mogoče dodati priključne module, denimo Mikro Elektonikin relejski modul za krmiljenje električnih naprav. Tak projekt najdemo tudi na spletni strani [1]. S pomočjo storitev Google Cloud je mogoče s PIC-IoT kartico krmiliti rele kadarkoli in kjerkoli smo povezani v splet.
V spletu najdemo tudi kompleksnejše primere uporabe, ki vključujejo črpanje podatkov iz javno dostopnih spletnih strežnikov, denimo z vremenskimi podatki in napovedmi. Teh se lotimo v prihodnjem nadaljevanju. Tokrat pa nadaljujmo s shranjevanjem podatkov v AWS DynamoDB tabelo, ki je ena izmed ključnih funkcij kompleksnejših AWS IoT aplikacij in nam bo prišla prav v naslednjem nadaljevanju.
Kako deluje AWS DynamoDB?
Prenosa podatkov iz IoT naprave v AWS DynamoDB podatkovno zbirko se bomo lotili v dveh korakih: Za začetek pustimo AWS IoT naprave in prenos podatkov z MQTT sporočili ob strani, saj moramo najprej ustvariti tabelo, nato pa še pravilo za prenos z vlogo, ki lahko prenaša podatke vanjo.

Ko se lotevamo gradnje podatkovne tabele pogosto pomislimo na njeno strukturo, a DynamoDB je dinamična podatkovna baza, v kateri je dovolj če za vsako tabelo podamo zgolj glavni indeks. Dodajanje opcijskega sekundarnega sortirnega ključa za glavne ključe prepuščeno uporabnikom. Sam sem izhajal iz enega od primerov povezave AWS IoT naprave z DynamoDB, katerega avtor je za glavni ključ uporabil kar MAC ID AWS IoT modula, za opcijski sortirni ključ pa časovni žig (angl. time stamp) v obliki dolgega celega števila. Tako ima vsaka vrstica tabele unikatni indeks, sestavljen in MAC ID razvojne plošče in časovnega žiga. Poteg glavnega lahko podamo še pomožne sortirne ključe, medtem ko ostale stolpce DynamoDB tabele samodejno določi AWS med vnosom strukturiranih podatkov. Vsekakor je to veliko lažje kot pri popolnoma strukturiranih podatkovnih zbirkah. Če imamo samo eno IoT napravo, lahko namesto MAC ID za glavni ključ uporabimo katerikoli drug podatek.

DynamoDB je nekakšen križanec med dokumentno podatkovno zbirko, v katero lahko nalagamo dokumente s poljubno vsebino (denimo tako ko jo uporablja IBM Lotus Notes) in natančno strukturirano relacijsko podatkovno zbirko, kakršne so klasične Microsoftove, Oraclove in IBMove SQL podatkovne zbirke, pri katerih moramo vnaprej natančno opredeliti vso vsebino tabel.
Dodajanje in odvzemanje podatkov v DynamoDB tabele je enostavno, saj moramo pri vsakem vnosu obvezno podati le glavni ključ, ostali podatki so opcijski. To lepo vidimo tudi, ki na ekran izpišemo vsebino tabele. V glavi tabele je (brez uporabe skrivanja stolpcev) od leve proti desni vedno sestavljena množica stolpcev, od katerih vsak nastopa v vsaj eni vrstici tabele.
Denimo, če ima vrstica 1 naslednjo sestavo: <glavni ključ><podatek 1><podatek 2><podatek 3>, vrstica 2 pa: <glavni ključ><podatek 2><podatek 3><podatek 4>, bo pregled dokumentov vseboval naslednje stolpce: <glavni ključ><podatek 1><podatek 2><podatek 3><podatek 4>. Pri tem bo pri vrsticah brez določenega ključa prikazano prazno polje.
Iskanje po DynamoDB tabelah izvajamo z SQL stavki, pri čemer lahko izbiramo med več različicami tega programskega jezika. Izberemo pač tisto, ki nam najbolj ustreza glede na trenutno uporabljano programsko okolje in programsko opremo.

Shranjevanje podatkov v DynamoDB
AWS DynamoDB ni samo storitev za uporabnike, temveč je tudi osrednji del vseh AWS storitev, ki so izredno prilagodljive potrebam uporabnikov. Ko v AWS prek protokola MQTT prispe sporočilo AWS IoT naprave, ga AWS začasno shrani eno od zalednih tabel DynamoDB. Glavni ključ v tabeli je tema sporočila (angl. topic), ki mu je kot sortirni ključ dodan še časovni žig.
Zato ni nič nenavadnega, da lahko na primer z SQL stavkom: SELECT * FROM ‘load_to_db’poiščemo vsa sporočila na temo ‘load_to_db’. V prejšnjih nadaljevanji smo omenili, kako se imena tem vežejo na posamezne AWS IoT naprave, vendar pa označevanje, kot na primer: ‘$aws/things/ESP32-AWS-module/TOPIC1’ ni obvezno. Če uporabimo drugačno oznako, lahko vsebino še vedno poiščemo, svojem IoT računu, vendar pa ni neposredno povezana z IoT napravo, ki jo je poslala.
Čeprav bi brez posebne strukture označevanja težko povezali več tisoč naprav, kot so to v svoji AWS aplikacijo za razvojne plošče PIC-IoT storili pri Microchipu, s tem gotovo ne bomo imeli težav, če v svojo AWS aplikacijo povežemo svojo edino IoT kartico, kar je opazilo tudi veliko avtorjev primerov aplikacij na spletu.
Resnico na ljubo se zdi, da bili pri primeri AWS aplikacij zaradi slabšega poznavanja AWS storitev celo nekoliko bolj zapleteni, kot so novejši. Kljub temu jih ni težno poenostaviti. Zato poglejmo izsek programske kode v programskem jeziku C++, ki v AWS Dynamo DB tabelo TBL1 prenese novo vrstico:

char TOPIC_NAME_TEST[]=”loadtodb”;
sprintf(payload,payloadFormat,n1,n2,n3);
AWS_CLIENT.publish(TOPIC_NAME_TEST,payload);

Kot vodimo, moramo funkciji publish objekta AWS_CLIENT podati zgolj ime teme, v našem primeru smo se odločili za konstanto TOPIC_NAME_TEST z vrednostjo »loadtodb« in pravilno strukturirano vsebino po protokolu MQTT. Vsebina je množica ključev s podatki, ki jo opišemo med zavitimi oklepaji { in } tako, da za vsak podatek najprej podamo ime, nato pa njegovo vrednost. Na primer:
“{“X”:”3″,”Y”:”4″}” pomeni, da ima vrstica tabele poleg glavnega ključa, ki ga AWS DynamoDB samodejno doda iz imena tema, še dva ključa X in Y, v katera v konkretnem primeru shranimo podatka 3 in 4. K temu je treba dodati še, da programski jezik C++ ne razume ugnezdenih narekovajev. Zato moramo narekovaje znotraj deklaracije podatkovnega niza predznačiti s poševnico nazaj. Denimo, C++ deklaracija : char strdta[]=”{ “id”:”N007″, “X”:”3″,”Y”:”4″}” pomeni, da v znakovni niz strdta shranimo vrednost “{“id”:”N007″,”X”:”3″,”Y”:”4″}”, ki jo nato lahko oddamo s prej omenjeno funkcijo publish. Kot vodimo, vrednost id že opredeljuje ime stolpca AWS DynamoDB tabele, v katero nameravamo shranjevati vrednosti X in Y, ki imata v konkretni vrstici vrednosti 3 in 4.

Vendar AWS IoT Core storitve še ne vedo, da želimo iz AWS IoT naprave preneseno vsebino nadalje shraniti v lastno AWS DynamoDB tabelo. Tako se celotna vsebina MQTT sporočila shrani v pod izbrano temo v že omenjeno začasno DynamoDB tabelo, iz katere jo lahko poberemo z SQL stavkom, v katerem ko iskalni ključ navedemo ime teme, lahko pa tudi še kak drug podatek.
Naredimo AWS IoT pravilo za prenos podatkov
Podatke bomo iz AWS DynamoDB začasne tabele, kamor se začasno shranijo po prenosu prek MQTT, shranjevali v lastno AWS DynamoDB tabelo, zato moramo izdelati podatkov. V splošnem lahko pravilo opredeljuje vse vrste prenosov, zato moramo biti previdni pri definiciji cilja prenosa. V našem primeru bomo izbrali Split message into multiple columns of a DynamoDB table (DyanmoDBv2), kar pomeni, da bo pravilo samodejno vneslo vsak podatek v sporočilu MQTT v poseben stolpec DynamoDB tabele. Druga možnost bi bila, da bi sporočilo shranili kot je, vendar bi ga potem z AWS storitvami težje obdelovali. Zato se je vsekakor bolje odločiti za drugo možnost.
Naslednji korak je izbira DynamoDB tabele, v katero bomo podatke prepisali. Če ustrezne tabele še nimamo, imamo zdaj priložnost, da jo izdelamo (gumb Create a new resource in na naslednjem zaslonu Create table). Veliko smo o DynamoDB tabelah smo že povedali, ostane le še nekaj tehničnih napotkov. Ime tabele je poljubno, vendar z nekaterimi omejitvami. Prav tako lahko izberemo poljubno ime glavnega ključa, njegov podatkovni tip pa iz šifranta. Vendar moramo pri tem paziti na ustreznost izbranega podatkovnega tipa glede na vrsto podatkov, ki jih želimo vanj shranjevati. Denimo, če bo glavni ključ časovni žig, moramo izbrati število (angl. number) in ne znakovni niz (angl. string), oziroma katero od ostalih izbir. Je pa res, da lahko v SQL stavku pravila izvedemo tudi razne pretvorbe podatkovnih tipov. V tem primeru moramo izbrati tisti podatkovni tip, ki je določen s pretvorbo. Če bomo glavnemu ključu tabele pridružili še sortirni ključ, bomo morali pravilno izbrati tudi njegov tip podatkov. Na primer, če bomo v pravilu uporabili SQL stavek: SELECT id, timestamp() as ts FROM ‘loadtodb’, bomo morali za glavni ključ izbrati podatkovni tip String za pridruženi sortirni ključ pa Number. Vsi ostali stolci tabele bodo nastali samodejno glede na prenesene podatke.

V rubriki Table Settings nam čarovnik za izdelavo tabele ponuja prednastavljene vrednosti, ki jih lahko vidimo in spremenimo le, če prej kljukico umaknemo. Večina si želi zastonjske ali vsaj čim cenejše tabele, zato umaknemo tudi kljukici za Read Capacity in Write Capacity, nato pa zmanjšamo vrednosti Read Capacity Units in Write Capacity Units na 1. Tako bo mesečni strošek tabele najnižji, oziroma pod 1 USB tudi, tudi če bomo AWS storitve uporabljali po enoletnem preizkusnem obdobju. Po kliku na Create malo počakamo, da AWS izdela tabelo in nas o tem obvesti.
Naslednji korak je priprava opisa ali opisov vlog, ki imajo dostop do določenih funkcionalnosti tabele. Za našo uporabo načeloma zadošča pravica pisanja, saj bomo podatke zgolj vnašali. Po drugi strani, mora vloga natančno opredeliti AWS storitve, IAM uporabnike in pravice dostopa do tabele. Zato moramo biti pri definiciji natančni, nikakor pa do ne pomeni, da moramo biti preveč »radodarni«, oziroma dovoliti tudi operacije, ki jih ne potrebujemo. Pravice dostopa posameznih uporabnikov opredeljuje politika, ki jo prilepimo na vlogo. Če je še nimamo, jo lahko prav tako ustvarimo. Več o tem smo povedali že v preteklih nadaljevanjih. Nazadnje s pritiskom na gumb Add action dodamo akcijo, ki jo bo izvajalo pravilo. Naslednji korak je opcijski, saj lahko dodamo tudi akcijo, ki se bo izvedla, če bo pravkar definirani akciji za prenos podatkov spodletelo. Ena izmed možnosti je tudi zapis napake v izbrano AWS S3 vedro, kar sem preizkusil tudi sam in moram napisati, da dobro deluje, še posebej, če vključimo verzoniranje vedra, saj se potem vsaka napaka zapiše kot nova verzija, v nasprotne, pa vidimo samo zadnjo napako. Zdaj lahko končno zaključimo pravilo s pritiskom na gumb Create rule in se lotimo njegovega testiranja.

Testiranje AWS pravila in AWS DynamoDB tabele
Testiranje pravilnosti delovanja AWS pravil in AWS DynamoDB tabel lahko opravimo tudi brez AWS IoT naprave, kar je navadno hitreje. V stranskem pregledu AWS IoT Core storitev najdemo meni Test, iz katerega se odpre okno za naročanje na sporočila in pošiljanje sporočil. Za testiranje pravkar ustvarjenega pravila, se najprej prijavimo na temo loadtodb (zavihek Subscribe to a topic), nato pa ponujeno pozdravno sporočilo zamenjamo na primer z naslednjim:
“{
“id”:”N007″,”X”:”3″,”Y”:”4″
}”
Po pošiljanju sporočila (zavihek Publish a topic) gremo iz konzole storitev IoT Core v konzolo DynamoDB, v kateri odpremo podatkovno zbirko TBL1 in preverimo, ali se je testni podatek prenesel vanjo. Če se ni, sta najverjetnejša vzroka napačne dostopne pravice vloge, ki ima dovoljenje za vpis podatkov v TBL1 ali napačni tipi podatkov pri definiciji polj tabele TBL1. Denimo, stolpec za vpis časovnega žiga mora biti število. Kot smo že omenili, lahko napako pri prenosu podatkov v tabelo tudi shranimo npr. v vedro S3 in nato zapis natančno preučimo.
V zadnjem koraku testiranja naložimo in poženemo še ugnezdeno programsko opremo v AWS IoT kartici. Ko začno v AWS oblak prihajati MQTT sporočila, se samodejno z njimi polni tudi tabela, kar lahko ponovno preberimo v konzoli AWS DynamoDB. Primer vgrajene programske kode za ESP32, ki sem ga uporabil pri testiranju AWS DynamoDB storitev je objavljen na spletni strani https://sites.google.com/site/pcusbprojects.
Prihodnjič

AWS storitve omogočajo veliko načinov uporabe in hkrati predstavljajo močno alternativo nakupu, lastnih računalniških sistemov. V prihodnjem nadaljevanju bomo preverjali varnost in zanesljivost uporabe AWS storitev. Podrobneje se lotimo tudi razvojnih plošč z Microchip WFI32E Wi-Fi modulom, ki združuje USB in Wi-Fi povezljivost v enem čipu. Preverili bomo tudi novosti na področju razvoja ESP32 modulov in alternativne oblačne IoT združljive infrastrukture, Google Cloud in Microsoft Azure.

Viri:
1: https://bit.ly/3vQU80j

Avtor: dr. Simon Vavpotič
https://sites.google.com/site/pcusbprojects