Here is the link to part one of this series, you might want to start there.

Based on the before stated principles and requirements for the prototyping platform I came up with the following architecture:

On the left, you see the web server where the HTML of the Prototyping tool will be stored. On the right, the different hardware components (sensors and actuators, e.g. buttons, rotary encoders, LEDs) are connected to ESP8266 microcontrollers. In broad terms, ESPs are similar to Arduinos but also offer WiFi connectivity for a low price. In between sits a server to broker and translate the information coming from both sides.

The ESPs will send MQTT messages when the user interacts with the hardware components and receives them when the user interacts with the software part. The (static) HTML page will use the WebSockets protocol to send and receive messages.

These are the key components of the Prototyping platform. In the following, I will discuss individual components and provide additional details.

Source code and how-to will follow.

 

The Server of Servers and Wireless Connectivity 

The two servers shown in the diagram above (the web server and the communication server) are running on a single computer (yes, a Raspberry Pi, as you might have guessed).

The Raspberry Pi is a cheap single-board microcomputer. I am still using a Raspberry Pi 3, even though version 4 is already available. The v3 is fast enough for his purpose.

For the operating system, I chose the default Raspberry Pi OS desktop version. (I’ll explain why I chose the desktop version later on, so bear with me.)

Since I wanted to have wireless connectivity to exchange messages and access the web server, I added a WiFi dongle to the Pi and configured it to provide an access point. Thus creating its own WiFi network.

Now the ESPs know which WiFi to connect to and the IP address of the server is known as well. No need to open the web server or other parts of the solution up to the Internet. The core part of the solution needs no Internet connection and sets up its own WiFi network.

But in case the Pi has an internet connection, I forward the ethernet and the built-in WiFi connection to the access point connections to allow them access as well. This allows me for example to update the devices and access online services.

Note: the easiest way to access and set up the Raspberry Pi is to connect it via an ethernet cable to your computer and share your computer’s internet connection (Mac/Windows). A WiFi connection will drop when you follow the access point setup instructions.

Since the operating system and the data of the Pi are stored on a Micro SD card, it‘s really easy to make backups and to deploy last-minute changes. And when you remove the card, all the intelligence of the hardware platform and the prototype are gone.

As you can see, the Pi has several jobs: it is the WiFi access point, it needs to provide a web server, an MQTT broker (which is needed to send/receive MQTT messages), and provides the communication server. An additional admin interface for the communication server would also be nice.

The Pi should share the web server’s folder on the network to allow for an easy way to upload the HTML prototypes. It should also be accessed remotely, to edit and to configure it, if needed.

In the next part, I will start describing the different components in more detail.

Stay tuned…