IoT Dashboard Integration with ThingSpeak

 What I set out to do 

After finishing the Simulink model, the next phase was the IoT integration. The project title is an IoT-based wind energy monitoring system, so connecting the simulation to a real cloud dashboard was a deliverable, not optional. The goal is to get live turbine data transmitting from MATLAB to ThingSpeak and displaying on a dashboard that anyone could view remotely.

Why ThingSpeak

The first decision was choosing which IoT platform to use. Some of the options I considered were:
  • ThingSpeak (MathWorks) – built into the MATLAB ecosystem, free to use, no extra setup.
  • Grafana – more powerful, but requires a local server or paid hosting
  • AWS IoT Core – professional grade but too much for a simulation project.
ThingSpeak was the most sensible choice. It's made by MathWorks, the same company as MATLAB, so there's a built-in toolbox that handles the connection without any web programming. Since the entire project was already in MATLAB, adding an IoT link meant writing 15 lines of code rathat than getting involved with a completely new platform.

Setting up the ThingSpeak Channel

The channel was set up at thingspeak.com with six fields mapping directly to the MATLAB simulation outputs:
  • Field 1: Turbine 1 Power (W)
  • Field 2: Turbine 2 Power(W)
  • Field 3: Turbine 3 Power(W)
  • Field 4: Turbine 4 power(W)
  • Field 5: Total grid power(W)
  • Field 6: Stability Metric


The one-to-one mapping between MATLAB variables and ThingSpeak fields was deliberate. It meant the dashboard directly reflected the simulation output without any intermediate processing, making it easier to verify that what was transmitted matched what MATLAB calculated.

Writing the Transmission Script

The data transmission script (thingspeak_upload.m) runs a loop that:
  • Takes the base turbine power values (1.8, 2.3, 1.5, 2.6W)
  • Adds small Gaussian noise to simulate live wind fluctuation
  • Calculated the total grid power by summing all four turbines
  • Calculates the stability metric using the same gain factor of 12 as the Simulink model
  • Writes all six values to the ThingSpeak channel in a single call

A few decisions I made:

Why Gaussian noise? The same noise model was used in the multi-turbine MATLAB code. Using it here keeps the ThingSpeak data consistent with the simulation - the values fluctuate realistically around the base turbine outputs.

Why pause(20)? ThingSpeak's free tier enforces a minimum 15-second interval between writes. Setting it to 20 seconds gives a small buffer to prevent rate limit problems.

Why a Gain factor of 12? The stability metric sent to ThingSpeak uses the same calculation as the Simulink Gain block. This means the value on the dashboard (around 98.4 for nominal conditions) is directly comparable to what the Simulink model displays - an important consistency check across all three implementations.

Problems I ran into

Rate limit error - The first time I ran the ThingSpeak code, I got an error saying that the requests were too frequent. This was because I had initially set the pause to 16 seconds. Increasing it to 20 fixed it.

Fields format error -  The ThingSpeakWrite function showed an error about the Fields variable needing to be a numeric vector. I fixed it by changing {1,2,3,4,5,6} to [1,2,3,4,5,6]. Curly brackets create a cell array, and square brackets create numeric arrays and the function required numeric.

These were both fixed quite easily but deserved to be documented anyway, as they show the kind of debugging that happens in real IoT integration work.

What the Dashboard Shows

Once the script was running, the ThingSpeak channel updated every 20 seconds with live data from all six fields. The Total Grid Power field fluctuates around 8.2W as expected. The stability metric stays around 98.4, consistent with the Simulink model and MATLAB advanced analysis results.


Connecting Everything Together

One of the things this phase made me realise is how well the three implementations cross-validate each other:
  • MATLAB calculates: total = 8.2W, stability = 98.4
  • Simulink displays: 8.2W and 98.4 on its display blocks
  • ThingSpeak receives values around 8.2W and 98.4 every 20 seconds
All three agree. That consistency across three different tools - Code, block diagram and the IoT Dashboard - is the strongest evidence that the analytical approach is working.


Connection to Research Problems

The ThingSpeak dashboard directly addresses the third research problem – system inefficiency from uncoordinated operation. A live remote dashboard means operators no longer need to be physically present to monitor the farms. Any underperforming turbine shows up as a lower value in its individual chart, and the total grid power field gives instant visibility of total system performance.


































Comments

Post a Comment

Popular posts from this blog

MATLAB Coding and Initial Data Analysis

Image
Writing the MATLAB script I developed two main MATLAB scripts: wind_turbine_analysis.m - Single turbine simulation using dataset multi_turbine_simulation.m - Multiple turbine wind farm simulation The first script loads the dataset (Voltage, Current, RPM, Power) and performs a comprehensive analysis as seen in the command window. The script automatically calculates mean, standard deviation, min and max for all variables, which gives us an insight into the system's variability and behaviour. What the time series shows. The voltage varies between approximately 5.8V and 11.4V over 60 seconds, following a smooth pattern that simulates varying wind conditions. The current response shows an inverse relationship; when the voltage is high, the current seems to be lower, which is realistic for a system with varying load conditions. Power output ranges from around 0.2W to nearly 5W, staying withing the specified 0-5W range. RPM and Power Relationship The scatter plot shows a clear positive co...
Read more

Week 1: Project Overview

Image
Designing and implementing a small-scale wind energy system that combines data analytics, embedded sensing, Internet of Things connectivity, and simulation-based validation is the goal of this project. The motivation behind this project is to gain hands-on experience with a complete engineering workflow, starting from physical energy generation and extending to real-time monitoring, MATLAB analysis, and digital twin modelling. Because wind energy is inherently changeable, it was selected as the focal point because it is perfect for showcasing real-time sensing, data processing, and system modelling. By using a controlled wind source such as a desk fan, the system can be tested repeatedly under different conditions while remaining safe and practical for indoor experimentation. This study closely relates to contemporary engineering techniques utilised in smart systems, predictive modelling, and renewable energy monitoring. Project Overview The project entails constructing a prototype mic...
Read more

Advanced Multi-Turbine Analysis - Methodology and Differentiation from Existing Solutions

Image
What I did: With the basic MATLAB analysis completed in week 3, this phase focused on a deeper investigation of the multi-turbine grid integration problems identified earlier. I need to test multiple scenarios to understand which factors most affect grid stability, power output, and system efficiency. Test conditions: Scenario 1: different turbine sizes 4 Turbines ranging from 0.4m to 1 m in diameter All turbines are exposed to the same wind speed of 5 m/s. Tests how physical size affects power contribution Scenario 2: different wind speed All turbines are 0.7m in diameter. Wind speeds range from 3 m/s to 7.5 m/s. Scenario 3: the perfect conditions All turbines and wind speeds stay constant for all turbines 0.6 m in diameter, 4.5 m/s wind This will be used as a baseline for comparison Scenario 4: worst case Extreme differences 0.3 m-1.2 m in diameter wind from 2 m/s to 8 m/s This will be used as a stress test for grid management. Key findings: Power variation analysis: Scenario 3 achie...
Read more