Technical progress

After my final thesis proposal last Sunday, I’ve shifted gears and started developing technical competences for my project. First I have set up a diagram for my understanding what kind of a system would I need to collect various sensors data and store it in one database. Because I want my microcontrollers to be remote and not dependent on wired connection I’ve decided to bridge ESP32 and Arduino Nano through Wi-Fi. I’ve started a github repository to store all the project code iterations and steps to document my workflow.

In my first experiment I’ve been able to set up Arduino as an AP (Access Point) and ESP32 as a client to communicate through HTTP requests and to turn on/off the integrated LED light on Arduino. After I’ve compiled sketches on the microcontrollers, I’ve followed what’s happening in serial monitor and realized that every time a request has been sent from the client, the connection has been closed by the server to enable listening for new connections and eventually new requests.

I believe this is not the best architecture for a system where you would like to have a constant stream of data through various devices in real time that’s why I’ve decided to set up a Node.js server with Sockets.io so that once a client is connected the data flows bidirectionally. I’ve set up client codes for ESP32 and Arduino, where I used WiFi NINA and WebSockets 2 Generic library but when I tried to connect I ran into a problem because the server is running on localhost:5000 and I couldn’t find a solution for connecting a client through an IP address in the local network. I’m not sure if there is a solution for this, but I’ve contacted Rudi and he pointed me in the right direction and helped me with a workshop by Stavrosdidakis called connected systems and interactive media. Here, I’ve learned about the MQTT messaging protocol for IoT devices, which is a lightweight publish/subscribe messaging transport and is ideal for connecting devices that are not necessarily on the same local network. MQTT broker is technically a server living on the “cloud” that receives messages from the clients and then routes the messages to appropriate destination. I think this is the best architecture solution for many-to-one system to have real-time data stored on the server side. 

Next Steps

  • schedule/production timeline
  • extensive academic research of my thesis topic
  • prototype of the space (sketches, Unity environment)
  • establishing many-to-one connection through MQTT protocol
  • preparing midterm presentation