This is part of a larger series, you might want to consider reading parts one and two first.

 

As promised, I will now discuss the parts of the platform in more detail – starting with the server.

The main job of the server is to connect the prototype’s HTML and the ESP devices via MQTT and WebSockets. In the first iteration, I used Node.js​ and Express to write it, resulting in about 600 lines of code. But since I am a UX designer and not a developer it’s probably best when I don’t write (a lot of) code.
The source code felt a bit crude and overly complex to me. It was hard for someone with little coding experience to get how the server worked. And that made maintaining and changing it hard for regular folks.

Luckily, I stumbled over an article describing Node-RED, a visual node-based programming language „for wiring together hardware devices, APIs and online services in new and interesting ways“. And it came pre-installed on the Raspberry Pi. So I gave it a try.

 

Node-RED FTW

It actually took me a while to wrap my head around the paradigm of node-based programming. But after that, I realized that Node-RED was a brilliant choice.

And after using Node-Red for about three years, I am still on my honeymoon with it. Node-RED is powerful, simple, and often beautiful, and its level of abstraction is just right.

To show you what I mean, here is the “source code” of the server:

To give you a bit more context of what you are looking at: the purple nodes are MQTT nodes, the olive ones are for WebSockets, the khaki one on the left is a node that evaluates the messages, and the one on the right stores a value in a variable.

The left flow listens for MQTT messages, determines their content, and sends some to the HTML page via WebSockets. The right one does the reverse: it waits for a web socket message, stores it, and sends it out via MQTT.
As you can see, the server consists of six core nodes (that is counting all but the dark green ones, as they are output nodes I use for debugging). And that’s all there is to it.

 

Detour: MQTT-Messages

Now, a quick detour to MQTT to help you to understand better how the server works…
MQTT is a topic-based protocol. You can subscribe to topics and you can send messages about them. All messages are handled by the MQTT broker. If you send a message about a topic, the broker forwards it to all interested parties (the subscribers). Topics have a hierarchy, using slashes. As an example, a topic for the IoT platform would be: iot/wemos01/button.
All topics of the IoT platform start with the iot prefix, followed by the element ID, and then followed by the (hardware) component. This is a topic the wemos01 would send when the button connected to the ESP is pressed.
If you now look to the (purple) MQTT node on the left, you see that it listens to the topic: iot/#. The # symbol is a wildcard, thus the MQTT nodes has subscribed to all topics starting with iot/. It receives all IoT platform topics.

With Node-Red, I went from 600 lines of code to only six nodes, which is quite a ratio! The flow is simple and easy to understand. You can look at it and can see what it does. Brilliant, isn’t it?

 

The Web Server

The one piece that is still missing, when we look at the architecture diagram, is the web server. But Node-RED comes to the rescue.
You design your Node-RED flows in your browser. This means Node-RED has a built-in web server. In its settings, you can define a folder for „static“ web pages. This is where we will place the prototype’s HTML and Node-RED will host them for us. Thus, Node-RED covers both the communication and the web server elegantly.

 

Outlook

This concludes the third installment of the series. I hope you find the pace and the level of abstraction ok.

Stay tuned to see what’s next – as I actually haven’t decided what the next part is about. It’s either about Axure or about the hardware components and the ESPs.
We will see…