Recently, one of the readers, Derrick, asked such questions in the comments:
I have done client/server stuff before but am new to WebSockets, hopefully, I can ask some questions –
1) How would this work if you wanted to ship ESP32 devices to different customers, and then let these customers stream in their ESP32 data using a separate internet-connected client (e.g., a web browser) via WebSockets? Can it work like this?
2) Does this only work if the ESP32 is on the same WiFi network, or can WebSockets also be used if the device is on a different network / remote?
3) In either case, what kind of configuration/setup is required? I saw you wrote something regarding needing the IP address(es) – is static IP required in this case (on either the client device or the ESP modules)? Is looking at the IP address assigned by the router the only way (i.e., if potential customers are both remote and non-technical, would such a setup be painful)?
I found these questions so interesting, that I decided to write a whole post trying to address them. I will start from the easiest one 🙂
Does WebSockets only work in the same network or can be used for devices in different networks or remote?
WebSockets are not limited to the same network. Whenever the Client is able to reach the Server (note the direction!) such a connection is possible. WebSockets server is simply a web server of a particular kind.
How would this work if you wanted to ship ESP32 devices to different customers, and then let these customers stream in their ESP32 data using a separate internet-connected client (e.g., a web browser) via WebSockets? Can it work like this?
In most cases, servers are placed under static IP somewhere on the Internet, and clients (like our browsers or phones) are connecting to them using the IP address or domain name. If you want to use the ESP module as the server, you have to make it visible from the Internet or from different networks your clients are in. This means that the router your ESP module is connected to has to be configured to forward incoming traffic to the ESP module.
As Derrick mentioned, one can use a web browser located in the same IP to act as a bridge between the ESP module and the remote endpoint. In such a case, the web browser will connect to the ESP WebSockets server and at the same time to the remote endpoint, the data should be sent to. The issue is that this makes setup more complicated.
In practice, it is easier to make ESP module the Client, not the Server. Yes, I’m talking about the opposite direction. Once the connection between the Client and Server is established, there is no forced direction of the data flow. The Client can send to Server and the Server can send to Client. The Client-Server direction is important only when the connection is made.
In my article about ESP8266 + Websockets = streaming data from the ESP module I was using ESP to collect information about moving objects. Kind of a game controller – it has to be fast and was required to work in a single network. If I were to collect data from multiple ESP modules in different networks, I would make them Clients. I would create a single Server that will record data provided by ESP modules (in the database or in memory – whatever does the job). Recorded data can be retrieved later, or if you have to review it on the fly – you can create a separate WebSockets endpoint on the same Server to send these data to the final receiver.
On the above image, all ESP modules are in different networks, Receiver is also in a different network. The directions on arrows mark the direction of the initial connections – ESP modules and Receiver are connecting to the Server. The server is located on the Internet and available from anywhere.
What kind of configuration/setup is required? Is looking at the IP address assigned by the router the only way (i.e., if potential customers are both remote and non-technical, would such a setup be painful)?
This is tricky. Usage of ESP modules in my case comes with the assumption that someone who is using them is able to handle the configuration. There is also an additional assumption, but I will get to it later. It can be greatly simplified by using the WiFiManager library (Better WiFi management on ESP8266 with WiFiManager) but this still requires customers to connect to the ESP module and to enter WiFi configuration. Here are the possibilities I see:
- Use WiFiManager and ship ESP modules with the proper manual. Client will have to collect their WiFi parameters (SSID and Password), then connect to the WiFi provided by ESP module and put this SSID and Password in the form provided by the module.
- You can collect SSID and Password information from your customers, pre-configure ESP modules and ship them already configured.
There are more possibilities, but the above is the simplest to execute. Now comes the additional assumption – in all cases, ESP modules will have to act as Clients and will have to connect to the Server placed somewhere on the Internet.
It is hard to provide the perfect solution knowing not much about the business case, hence the above considerations. When working with WebSockets it is worth knowing a few things though:
- WebSocket has no particular direction. Client is connecting to the Server, and this is when the direction matters. Data flow is equal in both directions.
- When working in the same network, EPS module can be Client or Server – it doesn’t matter if the second party is reachable.
- With different networks or remote work, it can be easier to configure ESP as Clients.
- Web chats are written using (among other things) WebSockets. Note that multiple Clients are connecting to the Server and the Server is forwarding messages from one Client to another. In practice, it can be multiple Clients posting to single Channel and one Receiver which is only listening what is going on on the Channel. Such architecture may help achieve the goal.