Build Blog 2: WebSocket Server/Client Architecture
- Dhruv Manani
- Feb 3, 2023
- 5 min read
Hey everyone! In this blog we'll go over the details of the software architecture that enable two-way communication between the different integral pieces that make up the Planter hydroponics system.
Software Architecture Overview
To understand why we need to use WebSockets to enable bidirectional communication between the components of the Planter system, lets first take a zoomed out view of the overall software architecture.
We can see that at the center of the system is a backend server, running on the cloud, that both sends and receives data as well as requests from the Raspberry Pi and User Portal (mobile application). The purpose of this backend server is to enable scalable feature development that allows a user to control and monitor their hydroponics system. The backend server is a bridge between the mobile application that the user interacts with directly, and the Raspberry Pi and database that are modified accordingly based on user requests and system needs. For additional information on the importance of this pipeline works from the user's perspective, see Mahad's Blog on Building the Connected Mobile App.
Full-Duplex Communication
Based on the needs of the project highlighted above, it was determined that a full-duplex protocol for communication was required. As illustrated in the diagram below, full-duplex enables simultaneous bidirectional communication between two nodes in the system. For the Planter use case this is necessary as we want both system control and monitoring at the same time. This means the user can modify system characteristics (send requests to the system) at the same time as the system sends sensor data to the user portal.
Why WebSockets?
For bidirectional real-time communication between servers and clients, many protocols and APIs are available. To choose the best one for this project, we considered the following options.
Protocol Name | Brief Description | Advantages | Disadvantages |
WebSocket | Communication protocol between server and client via a single TCP connection |
|
|
Server-Sent Events | Server push based protocol, where client subscribes to stream of events generated by server |
|
|
MQTT | Publisher (producer) and subscriber (consumer) based messaging protocol where middleware MQTT server handles message exchanges |
|
|
WebRTC | Framework for enabling realtime transmission of data in peer-to-peer manner |
|
|
WebTransport | Client-server messaging protocol that uses HTTP/3 |
|
|
Based on the above research, WebSockets were chosen as they provide "a real-time protocol that provides a persistent, full-duplex communication channel between a web client (e.g., a browser) and a web server over a single TCP connection" [2]. In essence, the use of the WebSocket protocol enables simple yet scalable communication between servers and clients via a method that is widely supported and relatively standardized. Another point worth mentioning is that WebRTC also came as a promising protocol for some of the use cases of Planter. For instance, for streaming camera data of the hydroponics system, WebRTC may be useful; thus, we will keep this in mind as we continue to develop the software stack for Planter.
Using WebSockets for the Planter system
Socket.io
Many libraries and APIs are available that implement the WebSocket protocol for different programming languages and use cases. For the purpose of this project, Socket.io was chosen as it provided the simplest, scalable and reliable communication with good performance. Furthermore, in deciding to use Socket.io, we considered the rest of software stack; namely, the use ReactNative for the mobile app (as discussed in Mahad's blog), Python for development on the RaspberryPi, and Node.js for the backend server. Socket.io is well supported on all three of these and very well documented.
Proof-of-Concept Development
The begin the development of this communication pipeline, I started off with the backend server. As someone who mainly works on embedded software that's closer to the hardware level, all of this was very new to me. I watched numerous videos and tutorials (including this very helpful one) and got started with setting up the communication pipeline. Using Express with Node.js and following this tutorial, I was able to get a server up and running fairly quickly. To begin, a simple toggle switch was styled onto the server that could allow some GPIO pin on the Raspberry Pi to be flipped. On the Raspberry Pi side, I developed a Python program that used the RPi-GPIO library to access and control GPIO pins. Initially, the Server was just hosted locally on the network and the Raspberry Pi was made to connect to this local host. Both on the server and client, I got setup with Socket.io and started writing some simple code to forward a request from the server UI (client) to the backend server in Node.js (server) to the Raspberry Pi (client).This request essentially triggered the Raspberry Pi to toggle a GPIO pin.
Success! While it may seem simple and almost trivial at first, we've essentially enabled bidirectional communication between a backend server and any number of clients. This simple LED example provides a proof-of-concept that can be scaled and built upon to add features such as transmitting pH and EC sensor data, controlling the plant lights of the system, monitoring the system health and status, and enabling the user to interact with their hydroponics system.
Further developing the server and clients
In the final system, the backend server talks to two clients, the Raspberry Pi and the mobile app. On the mobile app side, Mahad has integrated Socket.io with his code to collect and display metrics and provide the users with system configuration settings for the hydroponics system. We've tested this pipeline out and are able to get requests sent from the mobile app to the backend server, which then forwards them to the Raspberry Pi. On the Raspberry Pi side, I've structured the code into a class namespace structure (recommended by socket.io) which enables us to setup all the callback functions that enable different data and request flows in the system. I also got a periodic sensor data emitter working that runs as a background task through socket.io and regularly sends the backend server sensor data that is read by the Pi to be stored into the database.
Future Work
We've got off to a really good start with the software stack and will need to keep up this level of effort to get the hydroponics system working with all its functionality. Up next on the software side is to start integration with the sensors and actuators of the system. Currently, I'm working on my own Raspberry Pi 3B+, which is different than the Raspberry Pi Zero 2W that will go into the final system. The Pi Zero will be soldered onto a custom PCB that Abhi designed and is currently being printed. Once that's ready we'll be able to transfer over my code to that Raspberry Pi and start testing with real sensor data.
Another feature that we're working to develop is live streaming of the camera feeds inside the hydroponics system. This will enable users to see their plants in real-time through the mobile application. To do this, we'll need to use a protocol different than WebSockets, maybe something like WebRTC. Stay tuned for more blogs on this upcoming work!
References
[1] J. Hopkins, “Difference between half-duplex vs full-duplex,” Total Phase Blog, 19-Oct- 2022. [Online]. Available: https://www.totalphase.com/blog/2022/10/difference- between-half-duplex-vs-full-duplex/. [Accessed: 30-Jan-2023].
[2] “Websocket alternatives for realtime features,” Ably Realtime, 23-Nov-2022. [Online]. Available: https://ably.com/topic/websocket-alternatives. [Accessed: 30-Jan-2023].
留言