Komunikacja w projekcie sensnode

Myślę, że najwyższa pora przedstawić projekt od strony komunikacji pomiędzy urządzeniami oraz zastosowane sposoby(protokoły) wymiany danych. Postanowiłem wykonać schemat blokowy jak taka komunikacja by zachodziła.

Zacznijmy od bramki, która to spełnia istotną rolę w całym projekcie. Bramka podłączona jest przewodowo(USB) z sensBase i odbiera dane z nadajników w formacie JSON. Odbywa się to z wykorzystaniem komunikacji szeregowej przy prędkości 115200bps. Bramka dokonuje konwersji protokołów, z szeregowego na TCP wykorzystując „ser2net„. Urządzenie to zwykły router WiFi z zainstalowanym OpenWrt, oraz jednym portem USB. Idealnym kandydatem jest TL-Link WR703N, ze względu na rozmiary i cenę. Z powodu   ograniczonych zasobów takiego routera (pamięć flash) należało by zastosować lekki język skryptowy. Padło na lua’e, z kliku względów. Po pierwsze oficjalnie wykorzystywany w OpenWrt(luci), po drugie istnieją już potrzebne nam moduły, np. do mqtt i json. To właśnie napisany w tym języku skrypt zamieniał by dane z JSON na postać krótkich wiadomości MQTT. Protokół ten pozwala na szybką wymianę danych pomiędzy urządzeniami wykorzystując TCP, stąd ta bramka. Zgodnie ze specyfikację MQTT wysyłana informacja składa się z tytułu(topic) oraz samej wiadomości(message). W tym projekcie topic wyglądał by następująco „node/5.0/sensor/temperature”, a cała informacja z sensnodeTX:

node/5.0/sensor/temperature 23.7

Pozwala to w łatwy sposób wykorzystując maskę, subskrybować wybrane wiadomości, np. temperaturę ze wszystkich punktów(nodów).

Jeszcze jedno, bramek może być wiele. To pozwala w łatwy sposób rozszerzać całą infrastrukturę, a dzięki znacznie większemu zasięgowi sieci WiFi niż tych na paśmie 443Mhz, rozpiętość naszej sieci sensorowej(WSN) może być spora.

Wymiana danych pomiędzy bramkami, a serwerem następuje na zasadzie Pubsub – serwer subskrybuje informacje jakie wysyła mu publikator(bramka). Całość danych zapisywana jest w bazie danych MySQL lub innej relacyjnej bazie. Tutaj też odbywała by się cała wizualizacja, choć nie jest to koniecznością, gdyż można wykorzystać serwis zewnętrzny np. Pachube, który co ciekawe ma nawet własny serwer MQTT.

Aplikacja prezentująca dane z czujników powinna być prosta, oraz dostosowana do większości urządzeń klienckich(PC, laptopy, smatfony, tablety). Uważam, że pisanie aplikacji natywnej mija się z celem, gdyż taka aplikacja musi być ciągle rozwijana(nowe API, nowe urządzenia), a tak naprawdę każde z wyżej wymienionych urządzeń ma wbudowaną przeglądarkę WWW. Zastosowanie frameworku Django do napisania takiej aplikacji uważam za rozsądne wyjście, gdyż posiada sporą społeczność (w końcu to Python) oraz potrzebne moduły.