Ak využijete hotový hardvér pre monitorovanie výšky hladiny vody, či výšky sypkých materiálov, ktorý by ste chceli prepojiť s webaplikáciou Watmonitor pre vizualizáciu dát, môžete naraziť na limitácie, ktoré bránia priamej integrácii. To môže byť napríklad z dôvodu nepodpory HTTPS protokolu, čo je jediný komunikačný protokol Watmonitora, keďže ide o serverovú aplikáciu na klient-server architektúre komunikácie.
Samotná nepodpora nemusí znamenať, že by to samotný hardvér neumožňoval implementovať, ale častokrát má zariadenie uzavretý firmvér a ako používateľ viete pristupovať iba do konfiguračného rozhrania, kde si zvolíte jednu z podporovaných možností, ktoré sú otestované a meníte prakticky iba premenné, s ktorými program pracuje.
Typickým príkladom je mnoho NB-IoT zariadení, napríklad od Dragina (DDS75-NB - ultrazvukový snímač hladiny vody, LDS25-NB - LiDAR ToF snímač, PS-NB - tlakový snímač, MDS200-NB - mikrovĺnny radar), ktoré podporujú protokoly MQTT, MQTTS, UDP, TCP, COAP, pod ktoré HTTP / HTTPS nespadá a tak nie je možné poslať dáta priamo, aby ich webové rozhranie Watmonitora spracovalo. Obdobne to spadá aj pre iné zariadenia, napríklad od Ellenexu (rady PTX2, DUX2 - X označuje široké modely rady), ktoré podporujú UDP, LwM2M, MQTT, NIDD. Musíme preto do komunikácie pridať prostredníka, ktorý dáta prepošle na rozhranie Watmonitor po ich prijatí cez podporované rozhranie.
Ako najuniverzálnejší podporovaný protokol medzi týmito zariadeniami je MQTT. Budeme tak potrebovať MQTT Broker, spolu s backendom, ktorý bude fungovať 24/7 a spoľahlivo dáta spracuje a pushne na Watmonitor rozhranie. Ako vhodný kandidát prichádza platforma ThingsBoard, ktorá umožní implementovať túto logiku skrz Rule Chain, má non-stop dostupný MQTT Broker, ktorý je s platformou priamo prepojený. ThingsBoard je vhodný aj pre zariadenia, ktoré nepodporujú šifrované spojenie s Brokerom a ten je dostupný aj na štandardnom MQTT protokole 1883, ale tiež je plne podporovaný aj s TLS na porte 8883.
Implementácia MQTT routra na ThingsBoarde
V menu vyberieme Rule Chains, vytvoríme nový Rule Chain. Vzorovo si ho pomenujeme MQTT_router. Pred vytvorením samotného flowu zreťazených blokov logiky musíme plne chápať, ako funguje, resp. aké dáta prijímeme. Samotný blok input, ktorý sa automaticky v každom Rule Chaine nachádza má výstup, ktorý použijeme. Na tomto výstupe sa objavia dáta, ktoré príjdu na MQTT Broker od koncového zariadenia - klienta. Okrem dát ale obsahujú aj ďalšie meta informácie, ktoré určujú od ktorého validného klienta dáta sú. Pri Publishi dát (resp. už pri samotnom pripojení) na MQTT Broker Thingsboardu štandardne klient používa token, ktorým Publish autorizuje. Nemôžeme využiť priamo node REST API call z dôvodu, že k hodnote musíme pridať aj token (nastavený vo Watmonitore, nemá nič s ThingsBoardom).
Watmonitor štandardne očakáva:POST parameter: token (štandardne 123456789, ak nie je v inštancii nastavený iný)
Preto budeme musieť použiť node script z Transformation, ktorým si dáta payloadu pripravíme a to vrátane kľúčov (POST parametrov), tak aj hodnôt, ktoré k nim prislúchajú. Rule Chain navrhneme tak, že bude očakávať JSON kľúč "value" v ktorej bude uložená rozdielová, či celková výšky hladiny vody, ktorú snímač zaznamenal, teda celé číslo - integer.
Script node - nastavenie
Do tela scriptu (TBEL - ThingsBoard Environment Language) vložíme nasledujúci krátky kód:Kód:
var token = 123456789;
var hodnota = msg.value;
msg = "hodnota=" + hodnota + "&token=" + token;
return {msg: msg, metadata: metadata, msgType: msgType};
Tento script vytvorí premennú msg, ktorej priradí hodnotu získanú z value JSON kľúča, ktorý obsahoval hodnotu výšky hladiny vody, ktorý chceme dostať do Watmonitora. Tento script v podstate urobí takýto výstup do JSON kľúča msg (pre 123 value z JSON payloadu priradený do value):
"msg": "hodnota=123&token=123456789"
REST API Call - nastavenieParse to plain text - ZAŠKRTNÚŤ
V Headers: Content-Type - application/x-www-form-urlencoded
Zaškrnutie možnosti Parse to plain text je prakticky najkritickejšie nastavenie, bez ktorého nebudú správne prevedené JSON kľúče s hodnotami do POST atribútov requestu, ktorý bude REST API Call realizovať priamo na inštanciu Watmonitora. Aj keby ste mali všetky ostatné nastavenia správne, payload by bez Parse to plain text nebol v správnom formáte. Dbajte aj nato, aby ste mali nody script a REST API CALL prepojené skrz Success label pre úspešné preposlanie dát a fungujúcu automatizáciu.
Vytvorenie profilu zariadenia, zariadenieV ďalšom kroku si vytvoríme nový profil zariadenia v sekcii Profiles --> Device Profiles, pomenovali sme ho MQTT_profile_router. Na tento nový profil nastavíme už vytvorený a uložený Rule Chain MQTT_router. V sekcii Entities --> Devices vytvoríme nové zariadenia, ktoré pomenujeme device a nastavíme mu Device Profil MQTT_profile_router, čím zabezpečíme, že dáta prichádzajúce od tohto autorizovaného zariadenia spustia príslušný Rule Chain s názvom MQTT_router, ktorý dáta pushne priamo do Watmonitora skrz HTTPS POST request.
Otestovanie nanečisto
Po úspešnom uložení Rule Chainu, profilu aj samotného zariadenia môžeme prejsť na prvý test, ktorý overí, či dáta ThingsBoard spracuje, ale najmä, či ich dostane aj Watmonitor a uvidíme ich aj priamo v jeho dashboarde. Pre prvý test môžeme použiť Windows aplikáciu MQTTX Client.
Nastavenie MQTT údajov pre ThingsBoard:Server: mqtt.thingsboard.cloud
Topic: v1/devices/me/telemetry
Username: Access token z ThingsBoardu (v detaile zariadenia)
Payload (JSON): {value: 123}
Nastavenie pripojenia - Do Username dávame Access token, ktorý zistíme v detaile zariadenia. Do Client-ID môžeme zvoliť čokoľvek (pozor ale nato, že ide o verejný MQTT Broker). Ak zvolíte rovnaký Client-ID ako používa iný používateľ, budete sa striedavo odpájať z Brokera. Zadáme tiež URL MQTT Brokera (pozor, skutočne v URL je mqtt. nejde teda o
mqtt://, URL je tak v podstate
mqtt://mqtt.thingsboard-cloud.
Po nadviazaní pripojenia s automaticky vloženým Client-ID a používateľským menom z uloženého Connection sa môžeme na Broker pripojiť a odoslať dáta na prednastavený topic - v1/devices/me/telemetry s JSON payloadom, vzorovo {value:123}.
Samotné úspešné pripojenie (aj pred samotným Publishom dát na topic) uvidíte aj na ThingsBoarde, kde v Entities --> Devices uvidíte aktívne zariadenie, keďže sme sa na Broker pripojili priamo cez token tohto zariadenia.
Keďže sme mali správne nastavený script pre transformáciu payloadu a tiež aj node pre API CALL, dáta sa úspešne odoslali na Watmonitor vo formáte, ktorý očakáva t.j. HTTPS POST s Contenty type application/x-www-form-urlencoded. Backend Watmonitora tak dáta spracoval, uložil do MySQL (alebo MariaDB) databázy a následne vizualizoval aj vo svojej webaplikácii, či v AR vizualizácii, ako môžeme vidieť.
JSON súbory pre rýchly import a použitie profilu zariadenia a Rule Chainu do ThingsBoardu nájdete na:
https://github.com/martinius96/hladinomer-studna-scripty/tree/master/examples/Tools_Integrations/ThingsBoard/MQTT_ROUTERKeďže sú tu obsiahnuté aj iné integrácie s ThingsBoardom pre priame využitie JSON API endpointu Watmonitora, zvoľte si správne JSON súbory pre MQTT-to-HTTPS router.
Rule_Chain_mqtt_router.json - pre Rule Chain
mqtt_profile_router.json - pre profil zariadenia
Samotné zariadenie nemá .json súbor, ani možnosť exportu, musíte si ho vytvoriť manuálne. Je jedno, aké mu nastavíte meno, Rule Chain je spúšťaný na základe profilu priradeného k zariadeniu. Pri odosielaní dát ste limitovaní Watmonitorom, ktorý prijíma dáta max. raz za 200 sekúnd (ale štandardne až raz za 5 minút). Vo všetkých importovaných entitách môžete upraviť aj inštanciu Watmonitora na vašu bez nutnosti používať verejné testovacie webové rozhranie Watmonitora, ktoré bolo ukážkovo použité.
Táto Rule Chain automatizácia bude fungovať aj pre použitie MQTT, i šifrovaného MQTTS pripojenia na ThingsBoard Broker a tiež bude fungovať s HTTPS, ale aj HTTP inštanciou Watmonitora. Je tak plne na vás, akú kombináciu si vytvoríte. Fungovať bude aj MQTTS na HTTP, ale aj MQTT na HTTPS, ako sme si ukázali aj v článku.
Na strane ThingsBoardu môžeme použiť aj node message type switch z kategórie Filter, ktorým môžeme spustiť aj viac vetiev súčasne s využitím typu správy POST_TELEMETRY_REQUEST (teda vieme použiť label Post Telemetry ako reláciu medzi nodmi, ktoré sa vykonajú a budú vzájomne v nadväznosti fungovať), tento typ správny je automaticky vložený do JSON správy, keď sa realizuje Publish na topic v1/devices/me/telemetry. Môžeme takto pridať napríklad aj uloženie telemetrie ešte pred transformáciou payloadu. V tomto kroku sa uloží každý kľúč s hodnotou, ktorá prišla po MQTT na Publish topic od klienta, aj keby ich bolo viac. V prípade, že nemáme časovú značku, môžeme v node save time series využiť aj lokálny timestamp ThingsBoard platformy pre uloženie dát s touto časovou značkou. K uloženej telemetrii si môžete vytvoriť vlastnú vizualizáciu na platforme ThingsBoard.
