An IoT Telemetry Solution with NodeMCU ESP8266 and HiveMQ

HiveMQ welcomes this guest post from Hristo Hristov, an Industrial Data Engineer.

Getting real-time IoT data to the cloud isn’t easy with traditional tools. They often lack reliable, timestamped telemetry and cloud integration. Using a NodeMCU ESP8266, a Hall effect Sensor, a strong magnet, and the HiveMQ free tier cloud MQTT broker, we can build our own IoT solution to measure the real-time speed of any Lego RC model. With HiveMQ Cloud, we can have our telemetry data streamed in real time and available for visualization and downstream analytics. If you are an RC hobby vehicle enthusiast, here is a solution enabling real-time telemetry that you can build from scratch for about ten euros. 

The IoT Challenge: Real-Time Speed Tracking

If you are a Lego RC model enthusiast like I am, you may have wondered: how do I measure the speed of my model? How can I publish the speed readings to the cloud using MQTT to enable real-time visualization at a competition, further downstream data consumption, ETL, or analytics? One alternative would be to use something like a bicycle speedometer fixed inside your model. If the device happens to be a GPS-enabled one, it will work but you will have an issue: it will be impossible (or difficult!) to record your reading at regular intervals and push readings to the cloud for storage and analytics. 

IoT Solution: Real-Time RC Speed Tracking with MQTT

To enable real-time speed measurements and publish the data to a cloud MQTT broker, I decided to build a proof of concept using freely available hardware and the HiveMQ free service tier. As a result, I can take my Lego RC hobby to the next level by measuring the model speed in real time. The instantaneous speed tracking will allow me to precisely measure the performance of the model while operating on different gears and record the speed readings in m/s and km/hour.

Required Hardware and Software

Hardware list:

• 1x NodeMCU ESP8266, USB-C version with built-in Wi-Fi.

• 1x Digital Hall effect sensor.

• At least one 10x2 mm magnet or similar strong magnet. 

  • Recommended: eight magnets, arranged in four pairs, to be positioned 90 degrees from each other on one of the model wheels. 

• 1x 15 cm braided USB-A to USB-C cable. This cable will be used to connect the controller to a PC or to a power supply.

• 1x 10kΩ resistor.

• 1x breadboard for initial wiring and testing.

• Three male-to-male breadboard wires.

• Three male-to-female breadboard wires.

Here is what my components look like: 

Required software:

• Arduino IDE for developing the sensor reading and connectivity program. You can download the IDE for free using this link.

• A HiveMQ Cloud account for creating a cloud MQTT broker. If you have an existing account, that is fine. If not, you can sign up for the free tier using this link.

• Node-RED for visualizing the data. The easiest way is to run it under Docker. 

Hardware Setup 

This is what the controller looks like with the Hall effect sensor wired up using the breadboard:

The wires are connected the following way:

• brown from 3.3V GPIO power output, to sensor +

• white from GND GPIO to sensor ground

• blue from pinout GPIO4 to sensor data output.

Note the 10kΩ resistor that bridges the Hall sensor output pin and 3.3V. This bridge is required because the sensor has an open-drain output. As a result, when the sensor detects the magnet, it will pull the output to GND, and when no magnet is present the output will float or be undefined. To prevent this result, we need the 10kΩ resistor bridge. 

Here is what the whole setup looks like with an external power supply and wheel on a test bench. The wheel has a tiny magnet attached to its outside. In this way, I can easily test if the sensor successfully detects the magnet:

The Hall effect sensor connected to the device detects the magnetic field and converts it into electrical signals that the device can read. The sensor contains a thin piece of conductive material. When a magnetic field passes perpendicular to the current flow through this material, it creates a voltage difference across the material, called the Hall voltage. This happens because the magnetic field deflects the moving charge carriers to one side. The ESP8266 continuously polls this pin, and I can trigger an action when the state changes, which is perfect for speed detection. 

Software Setup

On the software side, the first task is to write a program that will do the following:

• Define variables for Wi-Fi connectivity, cloud MQTT broker address and credentials, root certificate, and a simple data structure for speed readings. 

• Define readings from the sensor.

• Calculate speed.

• Show the speed on a simple web interface.

• Connect to the HiveMQ broker to publish the readings as they become available from the device in real time. 

Here is a list of the methods the code in the GitHub repo contains:

Read our blog, Getting Started with MQTT on Arduino Using NodeMCU ESP8266, to learn more.

After uploading the source code to the device and booting it up, if all connection properties are set correctly, you should see the following messages in the Arduino IDE console:

At this point, the device is connected to both your Wi-Fi network and MQTT broker. Now the program is waiting for inputs from the sensor to begin the measurement and publish the results to the broker. 

Plotting the Measurements

Next, you can use Node-RED to develop a simple dashboard displaying current, minimum, and maximum speed values reached for the present session. I use the convenient Node-RED “MQTT in” node to subscribe to the broker in real time. The flow definition is also available as an attachment to this blog. Here is what the dashboard looks like:

The measurement output will also be visualized on the web page the device serves over port 80, as mentioned earlier. On the page, I included the current measurement as well as sensor status:

Having everything connected and all software configurations in place, let us take a step back and see what the benefit is of publishing the data to the cloud MQTT broker.

Why Use HiveMQ MQTT Broker

We could have easily stopped at this point where we have our telemetry measurement visualized on one or another web page, served directly from the controller. After all that satisfies a lot of scenarios, right? However, to enable more sophisticated future use cases, I decided to publish the data to the cloud using the MQTT communications protocol and an MQTT cloud broker. While I could have set up my own MQTT broker running locally, integrating with a cloud broker is more versatile overall. Additionally, having a cloud connection presents a universal data operations solution if there is internet connectivity. Therefore, I signed up for HiveMQ. After barely a minute or so, I had my own cloud broker set up and running:

Overall, I found it straightforward to open an account and set up the broker. Additionally, under the “Getting started” tab I found a great deal of documentation and sample code on how to integrate using Arduino or Python. If you are planning to have a high session count or lots of traffic, it might be best to check which paid tier will do the job for you. In any case, having your data flowing from the IoT device to the cloud MQTT broker at HiveMQ gives you the opportunity to:

• Have a real-time telemetry data hub; in other words, your own “unified namespace” (UNS).

• Connect tools for real-time visualization, e.g., Node-RED as described here. 

• Use a modular data engineering approach to connect to the broker, extract the data as soon as it arrives and store it in a database for historical analysis. 

Telemetry Device Onboard the Model

Finally, having the device fully wired up, connected and outputting the real-time measurement to the cloud, I completed the hardware setup by integrating it with one of my models. I attached the magnets to the inside of one of the rear wheels:

Then, I added the NodeMCU onboard the model, secured it and routed the wires appropriately. The sensor position must be close enough to the magnets. The wires should not be in the way of any moving parts, or gears:

With the device onboard, I could run an end-to-end test. In the video you can see the output from the device published to the cloud MQTT broker and visualized in real time, while cycling through the gears of the model:

Next Steps

When it comes to future iterations of this project, I have a few ideas in mind, related to both the hardware and software setup. When it comes to improving the accuracy of the speed measurement on the hardware level: 

• I could try adding more magnets for more reliable reading or use a better Hall effect sensor. 

• Design a 3D-printed pocket that attaches to the wheel to house one or two magnets for greater reliability. 

In terms of software improvements, I can consider: 

• Making further improvements related to the logic of recording the reading.

• Parametrizing when the device sends the current reading to the broker, which may result in saving bandwidth and broker traffic. 

• Developing a more sophisticated averaging buffer logic. 

Conclusion and Key Takeaways

In summary, it took ten euros and less than a day (not factoring in designing the Lego model!) to build and develop a solution that enables real-time telemetry and data collection using HiveMQ. While I built this solution for my pastime, the key principles remain the same across different applications and scenarios. One such principle is to use a compact fully programmable device with plenty of hardware connectivity options, low power draw and ability to run Python or C code. The HiveMQ Getting Started guide has a boilerplate code for both programming languages.

When it comes to cloud connectivity, it is convenient to use a cloud MQTT broker such as HiveMQ. Using the broker, you can publish your data loads in a fast and secure way, accounting for immediate changes. As a result, you can create your own unified data hub. Once the data is in the cloud, you can design downstream consumption or ETL solutions using the HiveMQ extensions for Snowflake or PostgreSQL, for example.