IoT - Comunicare corecta over internet + Mqtt

[Vizitator i2r]

Salutare. Am vazut ca exista pe forum diverse proiecte in care s-a abordat problematica comunicarii (achizitie, comanda etc.) prin internet (cu ESP8266, Ethernet shields cu arduino sau alte dev-boards etc). Eu intamplator ma incadrez la categoria cu ESP8266, dar postez aici pentru ca nelamuririle mele sunt mai degraba legate de concepte.

 

Consideram un scenariu basic de IoT / home automation in care am construit un device (sa-l numim MyDevice) capabil sa comunice over WiFi si pe care dorim sa-l interogam/comandam din extern (din afara LAN) prin internet. Nu avem IP static acasa si nici nu facem setari speciale de port forwarding (sau orice alta natura) prin router, UPnP este si el dezactivat. Un prim pas stiu ca este setup-ul MyDevice (prin diverse metode) astfel incat el sa stocheze parola si reteaua WiFi din casa, pentru a se putea conecta la ea. Vom comunica cu MyDevice printr-o aplicatie (cel mai uzual de smartphone, sa-i zicem MyApp) care nu poate insa interactiona direct cu MyDevice pentru ca nu-i stie IP-ul, la fel cum nici telefonul nu poate juca rol de server pentru ca nu poate avea un IP public cunoscut dinainte. De aici nevoia unui serviciu intermediar, hostat la o adresa stabila si cunoscuta, cu rol de message-broker (statistic majoritar este vorba de un MQTT broker, sa-l numim MyMqttBroker).

 

Aici vine nelamurirea mea: cum exact functioneaza MyMqttBroker (la nivel de protocol TCP): MyDevice se conecteaza la reteaua WiFi si poate initia un request HTTP catre MyMqttBroker (eventual sa-si faca remarcat IP public prin care "iese" din casa, daca e de folos la ceva); banuiesc/sper ca nu se tine alive o conexiune permanenta pentru ca este consumatoare de curent/timpi de procesare, respectiv nici MyDevice nu va intreba din cand in cand pe MyMqttBroker daca are ceva de executat (data pooling), pentru ca asta ar implica latenta. Mai ramane optiunea (corecta dupa cum o vad eu) ca MyMqttBroker sa notifice cumva MyDevice numai atunci cand e ceva de "vorbit" intre ei: dar cum poate initia un request http (sau poate de alta natura) catre MyDevice fara un port forwarding in router?

 

Cam aceeasi intrebare o am si legata si de MyApp care fie trasmite o comanda la MyMqttBroker (nu cunosc protocolul mqtt in detaliu dar banuiesc ca e un pattern pentru asta), fie face subscribe la un topic unde MyDevice face publish-ul discutat mai sus. Cum se face comunicarea asta de subscribe: se tine deschisa o conexiune TCP permanenta pentru push notification de la server, sau clientul face data pooling, sau e vreun mecanism de notificare fara conexiune permanant deschisa si care imi scapa mie?

 

Multumesc si scuze pentru topicul care s-a cam lungit...

 

[digix]

Daca vrei sa afli mai multe detalii, pune un broker mqtt, de exemplu Mosquitto si editeaza fisierul de configurare astfel incat sa scrie in fisierul log toata activitatea.

Stai cu ochii pe el in timp de postezi/subscrii la un topic si o sa te lamuresti.

[Vizitator i2r]

M-am lamurit intre timp dupa ce am studiat mai atent standardul acestui protocol: implementarile uzuale nu sunt peste Http ci peste TCP / WebSockets pentru a permite push notifications; deci exista o conexiune alive permanenta, de aici lipsa necesitatii de port forwarding in router, pentru ca nu va initia brokerul niciodata o conexiune catre MyDevice.

Imi era greu sa cred ca e un compromis viabil povestea cu conexiunea permanenta dpdv consum energie... dar aparent asta e realitatea.