Complete Project: AI-Powered IoT 3-Phase Transformer Monitoring, Protection and Agentic Automation Using ESP32 + ThingSpeak + Blynk + n8n + AI + Telegram Voice + Gmail + Google Sheets
This can be developed as a final-year/industrial IoT project with two layers:
-
Electrical monitoring/protection layer — ESP32 + isolated voltage/current/temperature sensors.
-
Cloud/AI automation layer — ThingSpeak + Blynk + n8n + AI Agent + Telegram + Gmail + Google Sheets + web dashboard.
The important engineering principle is that cloud/AI must never be the only protection mechanism. The ESP32 can detect abnormal conditions and command a properly isolated trip interface, but a real transformer installation should retain conventional protection such as breakers, fuses, thermal protection and appropriately engineered protection relays.
1. Project title
Recommended final title
“AI-Powered IoT-Based 3-Phase Transformer Monitoring and Protection System Using ESP32 with ThingSpeak, Blynk, Real-Time Web Dashboard and n8n Agentic Automation with Telegram Voice, Gmail and Google Sheets Alerts”
Short title:
“Agentic IoT 3-Phase Transformer Monitoring and Protection Using ESP32 + n8n + AI”
2. Project abstract
The proposed system is an IoT-enabled monitoring and protection platform for a three-phase transformer. An ESP32 microcontroller continuously measures electrical and environmental parameters including three-phase voltage, three-phase current, transformer temperature and selected fault conditions.
The sensor signals are electrically isolated from the high-voltage transformer circuits and conditioned to safe low-voltage levels before being sampled by the ESP32 ADC.
The ESP32 performs local calculations such as RMS voltage, RMS current, phase imbalance, overvoltage, undervoltage, overcurrent and temperature threshold detection. Local fault logic operates independently of the Internet connection.
Normal telemetry is transmitted to cloud services. ThingSpeak provides historical IoT data and visualization through its REST API. ThingSpeak's current documentation states that free users can update a channel every 15 seconds, while paid licenses can support faster updates. MathWorks+1
Blynk IoT provides a mobile/web dashboard and event notification mechanism. Blynk events can be generated from ESP32 firmware using Blynk.logEvent() and can generate push/email notifications according to the event configuration. Blynk Docs+1
An n8n automation server receives selected ESP32 events through a webhook. It can record events in Google Sheets, send Gmail notifications, generate an AI-based diagnostic explanation, and send a Telegram text or voice notification. n8n provides built-in Telegram and Gmail integrations and AI-agent functionality. n8n Documentation+2
The resulting system therefore becomes an agentic IoT architecture in which the ESP32 senses the physical system, local firmware detects immediate faults, cloud services store data, and an AI-enabled n8n workflow interprets events and distributes notifications.
3. Overall system architecture
┌─────────────────────────┐
│ 3-PHASE │
│ TRANSFORMER │
└───────────┬─────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
Voltage Sensors Current Sensors Temperature
VA / VB / VC IA / IB / IC DS18B20
│ │ │
└───────────────────────┼───────────────────────┘
│
▼
┌─────────────────────────┐
│ SIGNAL CONDITIONING │
│ Isolation / Filtering │
└───────────┬─────────────┘
│
▼
┌─────────────────────────┐
│ ESP32 │
│ │
│ RMS Calculation │
│ Fault Detection │
│ Local Protection Logic │
│ Wi-Fi Communication │
└───────┬─────────┬───────┘
│ │
┌────────────┘ └─────────────┐
│ │
▼ ▼
Protection Output Wi-Fi / Internet
│ │
▼ ▼
Trip Interface ┌──────────────────┐
/ Contactor* │ ThingSpeak │
└────────┬─────────┘
│
▼
Historical Data
│
┌───────────────────────────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Blynk Cloud n8n Webhook Web Dashboard
│ │
┌──────┴───────┐ ┌───────┼────────┐
▼ ▼ ▼ ▼ ▼
Blynk App Blynk Web AI Agent Telegram Gmail
│ │ │
▼ ▼ ▼
Diagnosis Voice Email
Alert
│
▼
Google Sheets
*For a real transformer, the actual breaker/contactor/protection scheme must be engineered separately. Do not connect an ESP32 GPIO directly to a mains circuit.
4. Functional block diagram
ELECTRICAL DOMAIN
┌────────────────────────────────────────────────────┐
│ │
│ 3-Phase Transformer │
│ │
│ Phase A ──► PT/Isolated Voltage Sensor ─┐ │
│ Phase B ──► PT/Isolated Voltage Sensor ─┤ │
│ Phase C ──► PT/Isolated Voltage Sensor ─┤ │
│ │ │
│ Phase A ──► CT/Hall Current Sensor ─────┤ │
│ Phase B ──► CT/Hall Current Sensor ─────┤ │
│ Phase C ──► CT/Hall Current Sensor ─────┤ │
│ │ │
│ Transformer ──► Temperature Sensor ─────┤ │
│ │ │
└──────────────────────────────────────────────┼──────┘
│
▼
┌────────────────────┐
│ ESP32 │
│ │
│ ADC sampling │
│ RMS calculation │
│ Fault detection │
│ Alarm generation │
│ Wi-Fi │
└────────┬───────────┘
│
┌────────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
Local Trip ThingSpeak Blynk
/ Alarm Cloud Cloud
│ │ │
│ │ ▼
│ │ Blynk App
│ │
│ ▼
│ n8n
│ │
│ ┌─────────┼─────────┐
│ ▼ ▼ ▼
│ AI Telegram Gmail
│ │ │ │
│ ▼ ▼ ▼
│ Diagnosis Voice Email
│ │
│ ▼
│ Google Sheets
│
▼
Physical alarm/
engineered trip
5. Hardware required
5.1 Controller
-
ESP32 DevKit V1 / ESP32-WROOM
-
USB cable
-
5 V regulated supply
-
3.3 V logic environment
The Arduino-ESP32 environment supports ADC operation and calibration APIs. ESP32 ADC readings are 12-bit by default, and attenuation must be selected according to the input range. Espressif Systems+1
5.2 Voltage measurement
For a real transformer installation, use an appropriately rated isolated voltage transformer/transducer or certified voltage transducer.
For a laboratory prototype, possibilities include:
-
Small isolation transformer + conditioning circuit
-
Certified AC voltage transducer
-
ZMPT-type isolated voltage-sensing module
Do not connect transformer primary voltage directly to an ESP32 ADC.
Conceptually:
Transformer Phase A
│
▼
┌──────────────────┐
│ Isolated PT │
│ / voltage │
│ transducer │
└────────┬─────────┘
│ low-level AC
▼
Filter / bias
│
▼
ESP32 ADC
Repeat for phases B and C.
6. Current measurement
Use an isolated current transformer or suitable Hall-effect current transducer.
Example architecture:
Phase A ────────┐
│
┌─────┐
│ CT-A│
└──┬──┘
│
▼
Burden/filter
│
▼
ESP32 ADC
Repeat for B and C.
For higher-current installations, the CT/transducer rating must be selected based on the transformer's actual current and protection requirements.
7. Temperature measurement
A DS18B20 is convenient for a prototype.
DS18B20
VCC ───────── ESP32 3.3 V
GND ───────── ESP32 GND
DATA ──────── GPIO 4
│
4.7kΩ
│
3.3 V
For an industrial transformer, use an appropriately rated temperature transmitter/RTD system rather than assuming a hobby sensor is suitable for direct installation.
8. Protection output
Recommended architecture:
ESP32 GPIO
│
▼
Optocoupler / isolated driver
│
▼
Interposing relay
│
▼
Engineered contactor/trip circuit
│
▼
Transformer protection system
Never:
ESP32 GPIO ───────► 230/415 V transformer circuit
The ESP32 is a low-voltage electronic controller.
9. Suggested ESP32 pin assignment
For a classic ESP32-WROOM/DevKit:
| Function | ESP32 pin |
|---|---|
| Phase-A voltage | GPIO32 |
| Phase-B voltage | GPIO33 |
| Phase-C voltage | GPIO34 |
| Phase-A current | GPIO35 |
| Phase-B current | GPIO36 |
| Phase-C current | GPIO39 |
| DS18B20 | GPIO4 |
| Trip output | GPIO26 |
| Buzzer | GPIO27 |
| Status LED | GPIO2 |
Using ADC1 pins is useful because the classic ESP32 has ADC1 channels on GPIO32–39. Espressif Systems
Important: exact ADC capabilities vary across ESP32 family members, so verify the particular board/SOC you use against its datasheet. Espressif Systems
10. Parameters monitored
The system can monitor:
Electrical
Example architecture:
Phase A ────────┐
│
┌─────┐
│ CT-A│
└──┬──┘
│
▼
Burden/filter
│
▼
ESP32 ADC
7. Temperature measurement
A DS18B20 is convenient for a prototype.
-
VAV_A
-
VBV_B
-
VCV_C
-
IAI_A
-
IBI_B
-
ICI_C
-
Frequency
-
Voltage imbalance
-
Current imbalance
-
Estimated apparent power
-
Estimated power factor if phase relationship is measured
Thermal
-
Transformer temperature
-
Ambient temperature
System
-
ESP32 online/offline status
-
Wi-Fi RSSI
-
Sensor fault
-
Protection state
-
Last alarm
-
Uptime
11. RMS calculation
For sampled AC voltage:
VRMS=1N∑i=1N(Vi−Voffset)2V_{RMS} = \sqrt{\frac{1}{N}\sum_{i=1}^{N}(V_i-V_{offset})^2}
For current:
IRMS=1N∑i=1N(Ii−Ioffset)2I_{RMS} = \sqrt{\frac{1}{N}\sum_{i=1}^{N}(I_i-I_{offset})^2}
where:
-
NN = number of samples
-
ViV_i = instantaneous voltage sample
-
IiI_i = instantaneous current sample
-
VoffsetV_{offset}, IoffsetI_{offset} = sensor midpoint/bias
For a prototype, calibrate each channel individually.
12. Fault-detection algorithm
A simple first version can use:
Read sensors
│
▼
Calculate RMS values
│
▼
Validate sensor readings
│
▼
Check temperature
│
├── High ───────────────► Temperature alarm
│
▼
Check voltage
│
├── High ───────────────► Overvoltage alarm
│
├── Low ────────────────► Undervoltage alarm
│
▼
Check current
│
└── High ───────────────► Overcurrent alarm
│
▼
Calculate imbalance
│
├── High ───────────────► Phase imbalance alarm
│
▼
Update local status
│
├── Critical ───────────► Local protection action
│
▼
Cloud telemetry
13. Example protection thresholds
These are demonstration values only, not universal transformer protection settings.
For example:
| Parameter | Warning | Critical |
|---|---|---|
| Phase voltage | ±5% | ±10% |
| Current | >90% rated | >110% rated |
| Temperature | 70°C | 85°C |
| Phase imbalance | 5% | 10% |
Actual thresholds must come from the transformer's nameplate, manufacturer documentation and engineered protection study.
14. Fault state machine
┌─────────────┐
│ NORMAL │
└──────┬──────┘
│
abnormal detected
▼
┌─────────────┐
│ WARNING │
└──────┬──────┘
│
critical condition
▼
┌─────────────┐
│ CRITICAL │
└──────┬──────┘
│
▼
┌─────────────┐
│ LOCAL TRIP │
└──────┬──────┘
│
▼
┌─────────────┐
│ LOCKOUT │
└─────────────┘
A lockout/reset strategy should be designed so that the system does not automatically re-energize dangerous equipment after a serious fault.
15. ThingSpeak channel design
Create one channel such as:
Transformer_01
Use the eight available fields for:
| Field | Parameter |
|---|---|
| Field 1 | VA |
| Field 2 | VB |
| Field 3 | VC |
| Field 4 | IA |
| Field 5 | IB |
| Field 6 | IC |
| Field 7 | Temperature |
| Field 8 | Fault code |
ThingSpeak's REST API supports reading/writing channel data, and a single channel message can carry multiple fields. MathWorks+1
For a free ThingSpeak account, design the firmware to send cloud telemetry at 15-second intervals or slower. Local ESP32 protection should operate much faster than the cloud update interval. MathWorks+1
16. ThingSpeak data flow
ESP32
│
│ HTTPS
▼
api.thingspeak.com
│
▼
ThingSpeak Channel
│
├── Field 1: VA
├── Field 2: VB
├── Field 3: VC
├── Field 4: IA
├── Field 5: IB
├── Field 6: IC
├── Field 7: Temperature
└── Field 8: Fault
17. ThingSpeak URL concept
The REST API uses the ThingSpeak API endpoint:
https://api.thingspeak.com/update
with parameters such as:
api_key=YOUR_WRITE_KEY
field1=230
field2=229
field3=231
field4=4.2
field5=4.0
field6=4.3
field7=52.4
field8=0
The official REST API documentation describes HTTP GET/POST operations for writing and reading channel data. MathWorks
Do not publish your actual Write API Key in a public GitHub repository.
18. Blynk architecture
Blynk Documentation
Create:
Template
│
├── Datastream: VA
├── Datastream: VB
├── Datastream: VC
├── Datastream: IA
├── Datastream: IB
├── Datastream: IC
├── Datastream: Temperature
├── Datastream: Fault
└── Datastream: Trip
Then create Events:
high_voltage
low_voltage
over_current
high_temperature
phase_imbalance
sensor_failure
transformer_trip
Blynk's current architecture uses device templates, datastreams and events for this type of IoT application. Blynk Docs
19. Blynk event operation
For example:
if (temperature > TEMP_CRITICAL) {
Blynk.logEvent(
"high_temperature",
"Transformer temperature exceeded critical limit"
);
}
Blynk documents Blynk.logEvent() for firmware-generated events, including an optional description. Blynk Docs+1
Blynk notifications can be configured as push/email/SMS depending on the platform and account configuration. Blynk Docs+1
20. Blynk mobile dashboard
Suggested screen:
┌─────────────────────────────────────┐
│ TRANSFORMER 01 │
│ ● ONLINE │
├─────────────────────────────────────┤
│ VA 231 V VB 229 V │
│ VC 232 V │
├─────────────────────────────────────┤
│ IA 4.2 A IB 4.1 A │
│ IC 4.3 A │
├─────────────────────────────────────┤
│ Temperature 52.4 °C │
├─────────────────────────────────────┤
│ Status: NORMAL │
│ Trip: OFF │
├─────────────────────────────────────┤
│ Voltage Graph │
│ Current Graph │
│ Temperature Graph │
└─────────────────────────────────────┘
Blynk provides both mobile and web dashboards for devices. Blynk Docs
21. Real-time web dashboard
A separate web dashboard can show:
╔══════════════════════════════════════════════╗
║ AI TRANSFORMER MONITOR ║
╠══════════════════════════════════════════════╣
║ STATUS: ● NORMAL DEVICE: ● ONLINE ║
╠══════════════════════════════════════════════╣
║ VOLTAGE ║
║ ║
║ R 230.5 V ║
║ Y 229.8 V ║
║ B 231.2 V ║
╠══════════════════════════════════════════════╣
║ CURRENT ║
║ ║
║ R 4.25 A ║
║ Y 4.10 A ║
║ B 4.30 A ║
╠══════════════════════════════════════════════╣
║ TEMPERATURE 52.4 °C ║
╠══════════════════════════════════════════════╣
║ AI STATUS ║
║ "No abnormal operating pattern detected." ║
╠══════════════════════════════════════════════╣
║ LAST EVENT ║
║ 26-09-2026 08:55 - NORMAL ║
╚══════════════════════════════════════════════╝
For a production design, don't expose ThingSpeak private credentials in browser JavaScript. Use an n8n API/webhook as a controlled backend.
22. Web dashboard architecture
Browser
│
│ HTTPS
▼
Web Dashboard
│
▼
n8n API/Webhook
│
├────────► ThingSpeak
│
├────────► Google Sheets
│
└────────► AI Agent
This allows credentials to remain server-side.
23. n8n architecture
n8n Documentation
n8n is especially useful here because it can connect APIs, messaging services, spreadsheets, email and AI workflows. n8n Documentation
Recommended workflow:
ESP32
│
│ HTTPS POST
▼
┌──────────────┐
│ n8n Webhook │
└──────┬───────┘
│
▼
┌──────────────┐
│ Validate JSON│
└──────┬───────┘
│
▼
┌──────────────┐
│ Normalize │
│ Sensor Data │
└──────┬───────┘
│
┌──────┴─────────┐
│ │
▼ ▼
Google Sheets AI Agent
│ │
│ ┌─────┴─────┐
│ │ Diagnosis │
│ └─────┬─────┘
│ │
└────────┬───────┘
▼
Severity Router
/ | \
/ | \
NORMAL WARNING CRITICAL
│ │
│ ├── Gmail
│ ├── Telegram text
│ └── Telegram voice
│
└─────── Telegram
24. ESP32 → n8n JSON
The ESP32 can send:
{
"device": "TRANSFORMER_01",
"timestamp": "2026-09-26T08:55:20",
"va": 231.2,
"vb": 229.8,
"vc": 230.6,
"ia": 4.25,
"ib": 4.10,
"ic": 4.30,
"temperature": 52.4,
"voltage_imbalance": 0.61,
"current_imbalance": 2.39,
"fault": 0,
"fault_text": "NORMAL",
"trip": false,
"wifi_rssi": -58
}
25. n8n workflow in detail
Node 1 — Webhook
POST /transformer-monitor
Receives the ESP32 JSON.
Node 2 — Code / validation
Example JavaScript:
const d = $json;
const required = [
"device",
"va",
"vb",
"vc",
"ia",
"ib",
"ic",
"temperature"
];
for (const key of required) {
if (d[key] === undefined || d[key] === null) {
throw new Error(`Missing parameter: ${key}`);
}
}
return [{
json: {
...d,
received_at: new Date().toISOString()
}
}];
26. Google Sheets database
Create a spreadsheet:
Transformer_01_Log
Columns:
Timestamp
Device
VA
VB
VC
IA
IB
IC
Temperature
Voltage Imbalance
Current Imbalance
Fault Code
Fault Text
Trip
AI Diagnosis
Severity
Action
n8n has a built-in Google Sheets integration, so the workflow can append each important event to a spreadsheet rather than making the ESP32 communicate directly with Google APIs. n8n Documentation+1
27. Google Sheets example
| Timestamp | Device | VA | VB | VC | IA | IB | IC | Temp | Fault |
|-----------|--------|----|----|----|----|----|----|------|-------|
| 08:50 | TR01 |230 |231 |229 |4.1 |4.0 |4.2 |51.2 |NORMAL|
| 08:51 | TR01 |231 |230 |232 |4.3 |4.2 |4.3 |51.5 |NORMAL|
| 08:52 | TR01 |241 |230 |231 |4.3 |4.1 |4.3 |52.0 |OVERVOLT|
28. AI Agent
The AI Agent should not replace deterministic protection logic.
Instead:
ESP32:
"What happened?"
AI:
"Why might it have happened?
What should the operator inspect?
How severe does the event appear?
What information should be logged?"
The AI receives structured information:
Device: TRANSFORMER_01
VA: 241 V
VB: 230 V
VC: 231 V
IA: 4.2 A
IB: 4.1 A
IC: 4.2 A
Temperature: 53°C
Fault: OVERVOLTAGE_A
29. AI Agent system prompt
Use something similar inside the n8n AI Agent:
You are an industrial transformer monitoring assistant.
Your job is to analyze structured telemetry from a three-phase
transformer monitoring device.
Never override or modify the physical protection decision.
The ESP32 is responsible for immediate protection.
Analyze:
- phase voltage
- phase current
- temperature
- voltage imbalance
- current imbalance
- fault code
- trip state
Return:
1. Severity:
NORMAL, WARNING, or CRITICAL
2. Diagnosis:
A concise explanation of the observed condition.
3. Possible causes:
Maximum three likely engineering causes.
4. Recommended inspection:
Maximum five safe inspection steps.
5. Operator message:
A concise message suitable for Telegram.
Do not claim certainty when the sensor data cannot establish the cause.
Never instruct an operator to bypass a protection device.
Never instruct anyone to touch an energized electrical circuit.
Do not issue commands to energize or re-energize the transformer.
30. AI Agent output example
Input:
VA = 241 V
VB = 230 V
VC = 231 V
IA = 4.2 A
IB = 4.1 A
IC = 4.3 A
Temperature = 53°C
Fault = OVERVOLTAGE_A
AI output:
{
"severity": "WARNING",
"diagnosis": "Phase A voltage is elevated relative to phases B and C.",
"possible_causes": [
"Supply-side phase voltage variation",
"Voltage-sensor calibration error",
"Abnormal upstream supply condition"
],
"recommended_inspection": [
"Verify the voltage measurement using an approved meter.",
"Check the sensor calibration.",
"Compare the condition with the other phases.",
"Inspect upstream supply conditions."
],
"operator_message":
"Transformer 01 warning: Phase A voltage is elevated. Verify the measurement and upstream supply."
}
31. Agentic IoT concept
This is where your project becomes more than a conventional IoT project.
Conventional IoT
Sensor
↓
ESP32
↓
Cloud
↓
Dashboard
Agentic IoT
Sensor
↓
ESP32
↓
Fault detection
↓
Cloud
↓
n8n
↓
AI Agent
↓
Interpretation
↓
Decision routing
├── Google Sheets
├── Gmail
├── Telegram
├── Voice alert
└── Dashboard
The AI interprets the event while deterministic embedded logic remains responsible for immediate protection.
32. Telegram architecture
Telegram can be used as the operator alert interface.
n8n's Telegram node supports sending messages and audio files, among other operations. n8n Documentation
ESP32
│
▼
n8n
│
▼
AI Agent
│
▼
Telegram Node
│
├── Text
│
└── Audio
33. Telegram text alert
Example:
🚨 TRANSFORMER ALERT
Device: TRANSFORMER_01
Severity: WARNING
Fault:
Phase-A overvoltage
VA: 241 V
VB: 230 V
VC: 231 V
Temperature: 53°C
AI assessment:
Phase A is elevated relative to the other phases.
Recommended action:
Verify the measurement and investigate the upstream supply.
Trip status: OFF
34. Telegram voice alert
The n8n workflow can convert the AI-generated message into speech and then send the resulting audio file using the Telegram node.
AI Agent
│
│ Text
▼
Text-to-Speech
│
│ MP3/OGG
▼
Telegram
│
▼
Operator's phone
For example, the spoken message could be:
“Warning. Transformer one has detected elevated voltage on phase A. Please verify the measurement and inspect the upstream supply.”
This is particularly useful for maintenance personnel who may not be watching the dashboard.
35. Gmail alert
n8n's Gmail integration can send an email message directly from the workflow. n8n Documentation
Example:
Subject:
Transformer 01 - CRITICAL OVERCURRENT ALERT
Device:
TRANSFORMER_01
Fault:
Overcurrent
IA: 8.6 A
IB: 4.1 A
IC: 4.3 A
Temperature:
62.3 °C
Trip:
ACTIVE
AI assessment:
Phase A current is significantly higher than phases B and C.
Recommended:
Inspect the current measurement and electrical load condition
using approved procedures.
36. Complete alert routing
Fault
│
▼
ESP32 detects
│
┌───────────┴───────────┐
│ │
▼ ▼
Local protection Cloud notification
│
▼
n8n
│
▼
AI Agent
│
┌────────┼─────────┐
│ │ │
▼ ▼ ▼
Gmail Telegram Sheets
│
┌──────┴──────┐
▼ ▼
Text Voice
37. ESP32 firmware
Below is a prototype/reference firmware architecture. The voltage/current conversion constants must be calibrated against the actual isolated sensor/transducer you install.
Install libraries:
Blynk
OneWire
DallasTemperature
WiFi
HTTPClient
The Arduino ESP32 platform provides analogRead, ADC attenuation and related ADC APIs. Espressif Systems
ESP32 code
#define BLYNK_TEMPLATE_ID "YOUR_TEMPLATE_ID"
#define BLYNK_TEMPLATE_NAME "Transformer Monitor"
#define BLYNK_AUTH_TOKEN "YOUR_BLYNK_TOKEN"
#include <WiFi.h>
#include <HTTPClient.h>
#include <BlynkSimpleEsp32.h>
#include <OneWire.h>
#include <DallasTemperature.h>
// --------------------------------------------------
// WiFi
// --------------------------------------------------
const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASSWORD = "YOUR_PASSWORD";
// --------------------------------------------------
// ThingSpeak
// --------------------------------------------------
const char* THINGSPEAK_API_KEY = "YOUR_THINGSPEAK_WRITE_KEY";
// --------------------------------------------------
// Pins
// --------------------------------------------------
#define VA_PIN 32
#define VB_PIN 33
#define VC_PIN 34
#define IA_PIN 35
#define IB_PIN 36
#define IC_PIN 39
#define TEMP_PIN 4
#define TRIP_PIN 26
#define BUZZER_PIN 27
#define STATUS_LED 2
// --------------------------------------------------
// Temperature
// --------------------------------------------------
OneWire oneWire(TEMP_PIN);
DallasTemperature temperatureSensor(&oneWire);
// --------------------------------------------------
// Thresholds - DEMONSTRATION VALUES ONLY
// --------------------------------------------------
const float TEMP_WARNING = 70.0;
const float TEMP_CRITICAL = 85.0;
const float V_NOMINAL = 230.0;
const float V_HIGH = 253.0;
const float V_LOW = 207.0;
const float I_MAX = 5.0;
// --------------------------------------------------
// Timers
// --------------------------------------------------
unsigned long lastCloudUpdate = 0;
unsigned long lastSensorRead = 0;
const unsigned long CLOUD_INTERVAL = 15000;
const unsigned long SENSOR_INTERVAL = 1000;
// --------------------------------------------------
// Data structure
// --------------------------------------------------
struct TransformerData {
float va;
float vb;
float vc;
float ia;
float ib;
float ic;
float temperature;
float voltageImbalance;
float currentImbalance;
int faultCode;
bool trip;
String faultText;
};
TransformerData data;
// --------------------------------------------------
// Read RMS from ADC
// --------------------------------------------------
float readRMS(int pin, float calibration)
{
const int samples = 500;
double sumSquares = 0;
double sum = 0;
for (int i = 0; i < samples; i++)
{
int raw = analogRead(pin);
sum += raw;
delayMicroseconds(200);
}
float offset = sum / samples;
for (int i = 0; i < samples; i++)
{
int raw = analogRead(pin);
float ac = raw - offset;
sumSquares += ac * ac;
delayMicroseconds(200);
}
float rmsADC = sqrt(sumSquares / samples);
return rmsADC * calibration;
}
// --------------------------------------------------
// Calculate imbalance
// --------------------------------------------------
float calculateImbalance(float a, float b, float c)
{
float average = (a + b + c) / 3.0;
if (average <= 0.001)
return 0;
float maxDeviation = max(
abs(a - average),
max(abs(b - average), abs(c - average))
);
return (maxDeviation / average) * 100.0;
}
// --------------------------------------------------
// Read all sensors
// --------------------------------------------------
void readSensors()
{
// IMPORTANT:
// These calibration values are placeholders.
// Calibrate against your actual isolated sensors.
data.va = readRMS(VA_PIN, 0.20);
data.vb = readRMS(VB_PIN, 0.20);
data.vc = readRMS(VC_PIN, 0.20);
data.ia = readRMS(IA_PIN, 0.002);
data.ib = readRMS(IB_PIN, 0.002);
data.ic = readRMS(IC_PIN, 0.002);
temperatureSensor.requestTemperatures();
data.temperature =
temperatureSensor.getTempCByIndex(0);
data.voltageImbalance =
calculateImbalance(
data.va,
data.vb,
data.vc
);
data.currentImbalance =
calculateImbalance(
data.ia,
data.ib,
data.ic
);
}
// --------------------------------------------------
// Fault detection
// --------------------------------------------------
void evaluateProtection()
{
data.faultCode = 0;
data.faultText = "NORMAL";
data.trip = false;
// Temperature
if (data.temperature >= TEMP_CRITICAL)
{
data.faultCode = 5;
data.faultText = "HIGH_TEMPERATURE";
data.trip = true;
}
// Current
else if (
data.ia >= I_MAX ||
data.ib >= I_MAX ||
data.ic >= I_MAX)
{
data.faultCode = 3;
data.faultText = "OVERCURRENT";
data.trip = true;
}
// Voltage
else if (
data.va >= V_HIGH ||
data.vb >= V_HIGH ||
data.vc >= V_HIGH)
{
data.faultCode = 1;
data.faultText = "OVERVOLTAGE";
data.trip = true;
}
else if (
data.va <= V_LOW ||
data.vb <= V_LOW ||
data.vc <= V_LOW)
{
data.faultCode = 2;
data.faultText = "UNDERVOLTAGE";
}
// Imbalance
else if (data.voltageImbalance >= 10.0)
{
data.faultCode = 4;
data.faultText = "PHASE_IMBALANCE";
}
// ------------------------------------------------
// Local protection output
// ------------------------------------------------
if (data.trip)
{
digitalWrite(TRIP_PIN, HIGH);
digitalWrite(BUZZER_PIN, HIGH);
digitalWrite(STATUS_LED, HIGH);
}
else
{
digitalWrite(TRIP_PIN, LOW);
digitalWrite(BUZZER_PIN, LOW);
digitalWrite(STATUS_LED, LOW);
}
}
// --------------------------------------------------
// Blynk events
// --------------------------------------------------
void sendBlynkEvents()
{
static String lastFault = "";
if (data.faultText != "NORMAL" &&
data.faultText != lastFault)
{
if (data.faultText == "HIGH_TEMPERATURE")
{
Blynk.logEvent(
"high_temperature",
String("Temperature: ") +
data.temperature + " C"
);
}
else if (data.faultText == "OVERCURRENT")
{
Blynk.logEvent(
"over_current",
"Transformer overcurrent detected"
);
}
else if (data.faultText == "OVERVOLTAGE")
{
Blynk.logEvent(
"high_voltage",
"Transformer overvoltage detected"
);
}
else if (data.faultText == "PHASE_IMBALANCE")
{
Blynk.logEvent(
"phase_imbalance",
"Three-phase voltage imbalance detected"
);
}
lastFault = data.faultText;
}
if (data.faultText == "NORMAL")
{
lastFault = "";
}
}
// --------------------------------------------------
// Blynk dashboard
// --------------------------------------------------
void updateBlynk()
{
Blynk.virtualWrite(V0, data.va);
Blynk.virtualWrite(V1, data.vb);
Blynk.virtualWrite(V2, data.vc);
Blynk.virtualWrite(V3, data.ia);
Blynk.virtualWrite(V4, data.ib);
Blynk.virtualWrite(V5, data.ic);
Blynk.virtualWrite(V6, data.temperature);
Blynk.virtualWrite(V7, data.voltageImbalance);
Blynk.virtualWrite(V8, data.faultText);
Blynk.virtualWrite(V9, data.trip);
}
// --------------------------------------------------
// ThingSpeak
// --------------------------------------------------
void sendThingSpeak()
{
if (WiFi.status() != WL_CONNECTED)
return;
HTTPClient http;
String url =
"https://api.thingspeak.com/update?api_key=" +
String(THINGSPEAK_API_KEY) +
"&field1=" + String(data.va, 2) +
"&field2=" + String(data.vb, 2) +
"&field3=" + String(data.vc, 2) +
"&field4=" + String(data.ia, 2) +
"&field5=" + String(data.ib, 2) +
"&field6=" + String(data.ic, 2) +
"&field7=" + String(data.temperature, 2) +
"&field8=" + String(data.faultCode);
http.begin(url);
int response =
http.GET();
Serial.print("ThingSpeak response: ");
Serial.println(response);
http.end();
}
// --------------------------------------------------
// Setup
// --------------------------------------------------
void setup()
{
Serial.begin(115200);
pinMode(TRIP_PIN, OUTPUT);
pinMode(BUZZER_PIN, OUTPUT);
pinMode(STATUS_LED, OUTPUT);
digitalWrite(TRIP_PIN, LOW);
digitalWrite(BUZZER_PIN, LOW);
analogReadResolution(12);
analogSetPinAttenuation(
VA_PIN,
ADC_11db
);
analogSetPinAttenuation(
VB_PIN,
ADC_11db
);
analogSetPinAttenuation(
VC_PIN,
ADC_11db
);
analogSetPinAttenuation(
IA_PIN,
ADC_11db
);
analogSetPinAttenuation(
IB_PIN,
ADC_11db
);
analogSetPinAttenuation(
IC_PIN,
ADC_11db
);
temperatureSensor.begin();
WiFi.begin(
WIFI_SSID,
WIFI_PASSWORD
);
Serial.print("Connecting WiFi");
while (
WiFi.status() != WL_CONNECTED)
{
delay(500);
Serial.print(".");
}
Serial.println();
Serial.println("WiFi connected");
Blynk.begin(
BLYNK_AUTH_TOKEN,
WIFI_SSID,
WIFI_PASSWORD
);
}
// --------------------------------------------------
// Main loop
// --------------------------------------------------
void loop()
{
Blynk.run();
unsigned long now = millis();
if (
now - lastSensorRead >=
SENSOR_INTERVAL)
{
lastSensorRead = now;
readSensors();
evaluateProtection();
updateBlynk();
sendBlynkEvents();
Serial.println(
"--------------------------"
);
Serial.printf(
"VA: %.2f VB: %.2f VC: %.2f\n",
data.va,
data.vb,
data.vc
);
Serial.printf(
"IA: %.2f IB: %.2f IC: %.2f\n",
data.ia,
data.ib,
data.ic
);
Serial.printf(
"Temperature: %.2f\n",
data.temperature
);
Serial.printf(
"Fault: %s\n",
data.faultText.c_str()
);
}
if (
now - lastCloudUpdate >=
CLOUD_INTERVAL)
{
lastCloudUpdate = now;
sendThingSpeak();
}
}
Important firmware note
The 0.20 and 0.002 conversion factors above are not universal sensor constants. They are placeholders for demonstrating the software architecture. You must calibrate:
ADC RMS
↓
known reference measurement
↓
calculate scale factor
↓
store calibration constant
Also, for high-accuracy AC measurement, use an appropriate sampling strategy and ADC calibration rather than assuming the nominal ADC reference is exact. Espressif documents ADC calibration because actual reference characteristics vary between chips. Espressif Systems
38. Improved production measurement architecture
For a serious version, I recommend:
TRANSFORMER
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
PT-A PT-B PT-C
│ │ │
▼ ▼ ▼
ADC/AFE-A ADC/AFE-B ADC/AFE-C
│ │ │
└────────────────┼────────────────┘
│
▼
ESP32
┌──────────────────────────────────┐
│ Current measurement │
│ │
│ CT-A → burden/AFE → ADC │
│ CT-B → burden/AFE → ADC │
│ CT-C → burden/AFE → ADC │
└──────────────────────────────────┘
For a higher-performance design, consider a dedicated metering ADC/AFE rather than relying entirely on the ESP32's built-in ADC.
39. ESP32 → n8n HTTP code
Add this function if you want event telemetry to n8n:
void sendToN8N()
{
if (WiFi.status() != WL_CONNECTED)
return;
HTTPClient http;
String url =
"https://YOUR-N8N-DOMAIN/webhook/transformer-monitor";
http.begin(url);
http.addHeader(
"Content-Type",
"application/json"
);
String json = "{";
json += "\"device\":\"TRANSFORMER_01\",";
json += "\"va\":" + String(data.va, 2) + ",";
json += "\"vb\":" + String(data.vb, 2) + ",";
json += "\"vc\":" + String(data.vc, 2) + ",";
json += "\"ia\":" + String(data.ia, 2) + ",";
json += "\"ib\":" + String(data.ib, 2) + ",";
json += "\"ic\":" + String(data.ic, 2) + ",";
json += "\"temperature\":" +
String(data.temperature, 2) + ",";
json += "\"voltage_imbalance\":" +
String(data.voltageImbalance, 2) + ",";
json += "\"current_imbalance\":" +
String(data.currentImbalance, 2) + ",";
json += "\"fault_code\":" +
String(data.faultCode) + ",";
json += "\"fault_text\":\"" +
data.faultText + "\",";
json += "\"trip\":" +
String(data.trip ? "true" : "false");
json += "}";
int response =
http.POST(json);
Serial.print(
"n8n response: "
);
Serial.println(response);
http.end();
}
Call it when an important event occurs rather than sending every second.
40. Recommended n8n workflow
Create these nodes:
[Webhook]
│
▼
[Code - Validate Data]
│
▼
[Google Sheets - Append Row]
│
▼
[Switch - Fault?]
/ \
NO YES
│ │
│ ▼
│ [AI Agent]
│ │
│ ▼
│ [Severity]
│ / | \
│ / | \
│ ▼ ▼ ▼
│ N W C
│ │ │
│ │ ├── Gmail
│ │ ├── Telegram
│ │ └── Voice
│ │
▼ ▼
Dashboard / Log
41. Normal event
ESP32
│
▼
n8n
│
▼
Google Sheets
│
▼
Dashboard
No Telegram/Gmail message is required for every normal sample.
42. Warning event
ESP32
│
▼
n8n
│
▼
AI Agent
│
▼
WARNING
│
├────► Google Sheets
│
├────► Telegram text
│
└────► Gmail
43. Critical event
CRITICAL
│
▼
n8n AI
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Gmail Telegram Google Sheets
│
┌────┴────┐
▼ ▼
Text Voice
The ESP32's local protection decision happens independently of this cloud workflow.
44. n8n AI agent tools
You can give the AI Agent controlled tools such as:
Tool 1:
Get latest transformer telemetry
Tool 2:
Get last 20 events from Google Sheets
Tool 3:
Get historical ThingSpeak data
Tool 4:
Write event to Google Sheets
Tool 5:
Prepare Telegram alert
Tool 6:
Prepare maintenance recommendation
n8n's current documentation describes AI Agents, tools, workflow tools and other AI workflow components. n8n Documentation
45. Agentic decision example
Suppose:
VA = 230 V
VB = 230 V
VC = 231 V
IA = 4.1 A
IB = 4.0 A
IC = 7.2 A
Temperature = 58°C
ESP32:
CURRENT FAULT
n8n:
Receive event
↓
AI Agent
↓
Compare phases
↓
Determine abnormal phase
↓
Generate explanation
↓
Send notifications
AI might produce:
Critical event: Phase C current is substantially higher
than phases A and B.
Possible causes include:
1. Unequal phase loading
2. Current-sensor issue
3. Downstream electrical fault
Verify the measurement and investigate the load using
approved electrical safety procedures.
46. AI should not control protection directly
Avoid this architecture:
Sensor
↓
AI
↓
AI says "Trip"
↓
Breaker
Prefer:
Sensor
↓
ESP32 deterministic protection
↓
Engineered trip circuit
and separately:
Sensor
↓
ESP32
↓
n8n
↓
AI
↓
Diagnosis + notification
This is one of the most important aspects of the project.
47. Complete communication architecture
┌──────────────────────┐
│ 3-PHASE TRANSFORMER │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Isolated Sensors │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ ESP32 │
│ │
│ RMS │
│ Fault Logic │
│ Local Protection │
└──────┬─────────┬─────┘
│ │
Local │ │ Wi-Fi
trip │ │
│ ▼
│ ┌──────────────┐
│ │ ThingSpeak │
│ └──────┬───────┘
│ │
│ ▼
│ Historical data
│
│ ┌──────────────┐
└──►│ Blynk │
└──────┬───────┘
│
Mobile/Web
ESP32 event
│
▼
n8n Webhook
│
▼
Validation
│
├──────────────► Google Sheets
│
▼
AI Agent
│
├──────► Gmail
│
├──────► Telegram text
│
└──────► TTS
│
▼
Telegram Voice
48. Data-flow diagram
[SENSORS]
│
│ Analog
▼
[ESP32 ADC]
│
▼
[RMS / Filtering]
│
▼
[Fault Engine]
│
├───────────────► [LOCAL ALARM]
│
├───────────────► [TRIP INTERFACE]
│
▼
[Wi-Fi]
│
├──────────────► ThingSpeak
│
├──────────────► Blynk
│
└──────────────► n8n
│
▼
[AI AGENT]
│
┌──────────┼──────────┐
▼ ▼ ▼
Gmail Telegram Sheets
│
▼
TTS
│
▼
Voice Alert
49. Dashboard hierarchy
A professional dashboard can contain four pages.
Page 1 — Overview
Transformer Status
Online
Normal/Warning/Critical
Trip state
Temperature
Page 2 — Electrical
Phase voltage
Phase current
Voltage imbalance
Current imbalance
Power
Frequency
Page 3 — Historical
24-hour voltage graph
24-hour current graph
Temperature graph
Fault history
Page 4 — AI Maintenance
Current diagnosis
Recent abnormal events
Possible causes
Recommended inspection
Last AI analysis
50. Database/event structure
A useful event record is:
{
"timestamp": "2026-09-26T08:55:20",
"device": "TRANSFORMER_01",
"event": "OVERCURRENT",
"severity": "CRITICAL",
"phase": "C",
"value": 7.2,
"temperature": 58.2,
"trip": true,
"ai_diagnosis": "Phase C current significantly exceeds phases A and B.",
"notification": {
"telegram": true,
"voice": true,
"gmail": true
}
}
51. Sensor calibration procedure
Voltage calibration
-
Disconnect the high-voltage system from the prototype electronics.
-
Use an appropriate isolated low-voltage AC test source.
-
Measure with a calibrated reference instrument.
-
Read the ESP32 ADC.
-
Calculate the conversion coefficient.
-
Repeat at several voltage levels.
-
Store calibration values.
Example:
Reference = 230.0 V
ESP32 calculation = 218.5 V
Calibration factor =
230 / 218.5
≈ 1.052
Do this independently for:
VA
VB
VC
52. Current calibration
Example:
Reference current = 5.00 A
ESP32 = 4.72 A
Factor = 5.00 / 4.72
= 1.059
Repeat for each CT/transducer.
53. Temperature calibration
Compare DS18B20 with a calibrated reference thermometer.
Reference = 50.0°C
Sensor = 49.2°C
Offset = +0.8°C
Store calibration.
54. Testing plan
Test 1 — ESP32
Check:
☐ ESP32 boots
☐ Wi-Fi connects
☐ ADC values available
☐ Temperature available
☐ LEDs operate
☐ relay interface operates
Test 2 — Sensor calibration
☐ VA calibration
☐ VB calibration
☐ VC calibration
☐ IA calibration
☐ IB calibration
☐ IC calibration
☐ temperature calibration
Test 3 — Normal operation
Expected:
Voltage: normal
Current: normal
Temperature: normal
Fault: 0
Trip: OFF
Test 4 — Overvoltage simulation
Use a safe low-voltage test source.
Expected:
ESP32 detects overvoltage
↓
Fault code
↓
Local alarm
↓
Blynk event
↓
n8n
↓
AI diagnosis
↓
Telegram
↓
Gmail
↓
Google Sheets
55. Test matrix
| Test | Input condition | Expected |
|---|---|---|
| T1 | Normal voltage | NORMAL |
| T2 | High phase-A voltage | OVERVOLTAGE |
| T3 | Low phase-B voltage | UNDERVOLTAGE |
| T4 | High phase-C current | OVERCURRENT |
| T5 | High temperature | HIGH_TEMP |
| T6 | Phase imbalance | IMBALANCE |
| T7 | Wi-Fi lost | Local protection continues |
| T8 | ThingSpeak unavailable | Local protection continues |
| T9 | Blynk unavailable | Local protection continues |
| T10 | n8n unavailable | Local protection continues |
| T11 | Sensor disconnected | SENSOR_ERROR |
| T12 | Power restored | Controlled startup |
56. Most important reliability test
Disconnect Internet/Wi-Fi.
Then simulate a fault.
The expected result is:
Wi-Fi OFF
│
▼
ESP32 still reads sensors
│
▼
ESP32 still detects fault
│
▼
Local alarm/protection still operates
This demonstrates that the protection function does not depend on the cloud.
57. Sensor failure detection
A good project should not assume that every ADC value is valid.
For example:
VA = 0
VB = 230
VC = 231
could mean:
Phase A absent
or:
Voltage sensor failed
Therefore add:
SENSOR_ERROR
and use sanity checks.
Example:
if (data.va < 5 &&
data.vb > 100 &&
data.vc > 100)
{
data.faultCode = 10;
data.faultText = "VA_SENSOR_ERROR";
}
For production, use more robust sensor diagnostics.
58. Internet failure strategy
Internet
│
┌────┴────┐
│ │
Online Offline
│ │
▼ ▼
Cloud Local only
│ │
▼ │
Dashboard │
│
Local alarm
Local trip
Cloud communication should be considered secondary telemetry, not the primary protection path.
59. Security architecture
Do not hard-code sensitive credentials in a public repository.
Protect:
Wi-Fi password
Blynk token
ThingSpeak Write API key
n8n webhook URL
Telegram bot token
Google credentials
AI API credentials
Recommended:
ESP32
│
├── Wi-Fi credentials
├── ThingSpeak key
└── Blynk token
n8n
│
├── Google credentials
├── Gmail credentials
├── Telegram credentials
└── AI credentials
This means the ESP32 does not need to contain every cloud credential.
60. n8n security
Use:
HTTPS
Authentication
Webhook secret
Credential store
Access control
instead of exposing:
http://public-server/transformer
without authentication.
A simple approach is:
POST /webhook/transformer-monitor
Authorization: Bearer YOUR_DEVICE_SECRET
Then validate the secret before processing the payload.
61. Better n8n webhook payload
{
"device": "TR01",
"auth": "DEVICE_SECRET",
"timestamp": 1758850000,
"measurements": {
"va": 230.5,
"vb": 229.9,
"vc": 231.0,
"ia": 4.1,
"ib": 4.0,
"ic": 4.2,
"temperature": 52.2
},
"protection": {
"fault_code": 0,
"fault": "NORMAL",
"trip": false
}
}
62. AI voice-alert workflow
ESP32
│
▼
n8n
│
▼
AI Agent
│
▼
"Transformer 01
has an overcurrent
condition..."
│
▼
Text-to-Speech
│
▼
Audio File
│
▼
Telegram Node
│
▼
📱 Operator
n8n's Telegram integration supports sending audio files, making this pattern practical. n8n Documentation
63. Telegram command interface
You can extend the project so an authorized operator can send:
/status
and receive:
Transformer 01
VA: 230 V
VB: 231 V
VC: 229 V
IA: 4.1 A
IB: 4.0 A
IC: 4.2 A
Temperature: 51.8°C
Status: NORMAL
Trip: OFF
Other safe commands:
/status
/history
/lastfault
/temperature
/voltage
/current
Avoid allowing unrestricted Telegram commands to energize or bypass protection hardware.
64. Example Telegram conversational flow
OPERATOR:
/status
BOT:
Transformer 01 is ONLINE.
Voltage:
A 230 V
B 231 V
C 229 V
Current:
A 4.1 A
B 4.0 A
C 4.2 A
Temperature:
51.8 °C
Status:
NORMAL
Then:
OPERATOR:
/lastfault
BOT:
Last event:
26-09-2026 08:41
Event:
Phase C overcurrent
Peak:
7.2 A
Trip:
ACTIVE
AI assessment:
Phase C current was substantially higher
than the other phases.
65. Project software architecture
┌─────────────────────────────────────────────┐
│ ESP32 FIRMWARE │
├─────────────────────────────────────────────┤
│ Sensor Driver │
│ ↓ │
│ Signal Processing │
│ ↓ │
│ RMS Calculation │
│ ↓ │
│ Protection Engine │
│ ↓ │
│ Event Manager │
│ ↓ │
│ ┌──────────────┬──────────────┐ │
│ │ Blynk Client │ ThingSpeak │ │
│ │ │ Client │ │
│ └──────────────┴──────────────┘ │
│ ↓ │
│ n8n HTTP Client │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ n8n │
├─────────────────────────────────────────────┤
│ Webhook │
│ ↓ │
│ Validation │
│ ↓ │
│ Database/Sheets │
│ ↓ │
│ AI Agent │
│ ↓ │
│ Severity Router │
│ ├── Gmail │
│ ├── Telegram │
│ ├── TTS │
│ └── Dashboard API │
└─────────────────────────────────────────────┘
66. Suggested project folder structure
Transformer-IoT/
│
├── ESP32/
│ ├── transformer_monitor.ino
│ ├── config.h
│ ├── sensors.h
│ ├── sensors.cpp
│ ├── protection.h
│ └── protection.cpp
│
├── n8n/
│ ├── transformer-monitor.json
│ ├── ai-prompt.txt
│ └── workflow-notes.md
│
├── dashboard/
│ ├── index.html
│ ├── style.css
│ └── app.js
│
├── documentation/
│ ├── architecture.md
│ ├── calibration.md
│ ├── testing.md
│ └── final-report.md
│
└── README.md
67. Suggested final-year project chapters
Your report can be structured as:
Chapter 1 — Introduction
Transformer_01
| Field | Parameter |
|---|---|
| Field 1 | VA |
| Field 2 | VB |
| Field 3 | VC |
| Field 4 | IA |
| Field 5 | IB |
| Field 6 | IC |
| Field 7 | Temperature |
| Field 8 | Fault code |
ThingSpeak's REST API supports reading/writing channel data, and a single channel message can carry multiple fields.
-
Background
-
Problem statement
-
Motivation
-
Objectives
-
Scope
Chapter 2 — Literature/Technology Review
-
Transformer monitoring
-
IoT
-
ESP32
-
Cloud monitoring
-
Blynk
-
ThingSpeak
-
n8n
-
AI agents
-
Telegram automation
Chapter 3 — System Design
-
Block diagram
-
Hardware architecture
-
Software architecture
-
Communication architecture
-
Protection architecture
Chapter 4 — Hardware Implementation
-
ESP32
-
Voltage sensing
-
Current sensing
-
Temperature sensing
-
Signal conditioning
-
Isolation
-
Alarm circuit
-
Protection interface
Chapter 5 — Software Implementation
-
ESP32 firmware
-
RMS algorithm
-
Fault algorithm
-
Blynk
-
ThingSpeak
-
n8n
-
AI Agent
-
Telegram
-
Gmail
-
Google Sheets
-
Web dashboard
Chapter 6 — Results
-
Normal operation
-
Overvoltage
-
Undervoltage
-
Overcurrent
-
Temperature
-
Imbalance
-
Internet failure
Chapter 7 — AI/Agentic Automation
-
AI prompt
-
Diagnostic process
-
Notification process
-
Voice alert
Chapter 8 — Testing
-
Test cases
-
Measurements
-
Accuracy
-
Response time
-
Reliability
Chapter 9 — Conclusion
Chapter 10 — Future Scope
68. Project objectives
Primary objective
To design an IoT-based three-phase transformer monitoring system capable of continuously measuring electrical and thermal parameters and providing local protection and remote notifications.
Secondary objectives
-
Measure three-phase voltage.
-
Measure three-phase current.
-
Monitor transformer temperature.
-
Calculate RMS values.
-
Detect overvoltage.
-
Detect undervoltage.
-
Detect overcurrent.
-
Detect phase imbalance.
-
Generate local alarms.
-
Provide an isolated protection interface.
-
Upload telemetry to ThingSpeak.
-
Display data using Blynk.
-
Build a web dashboard.
-
Integrate n8n.
-
Store events in Google Sheets.
-
Send Gmail alerts.
-
Send Telegram notifications.
-
Generate Telegram voice alerts.
-
Use an AI agent for event interpretation.
-
Maintain protection operation during Internet failure.
69. Key innovation
The strongest part of the project is not simply:
ESP32 + ThingSpeak
because that is a conventional IoT monitoring system.
The more advanced architecture is:
ESP32 + local protection + cloud telemetry + n8n automation + AI diagnostic agent + Telegram voice notification + historical event database.
The AI is therefore used for diagnostic intelligence and operator communication, while deterministic firmware performs immediate protection.
70. Advantages
-
Real-time local monitoring
-
Remote monitoring
-
Historical data
-
Mobile application
-
Web dashboard
-
Automated notifications
-
Voice alerts
-
Event logging
-
AI-assisted diagnosis
-
Google Sheets maintenance history
-
Internet-independent local fault logic
-
Expandable architecture
-
Suitable for academic demonstration and prototyping
71. Limitations
The prototype has important limitations:
-
ESP32 ADC accuracy is not equivalent to a certified power-quality meter.
-
Hobby-grade sensors may not be suitable for industrial transformer installations.
-
AI cannot determine the physical cause of a fault with certainty from limited sensor data.
-
ThingSpeak free accounts impose update-rate and other limits. MathWorks+1
-
Cloud services depend on network availability.
-
Blynk event notifications have platform limits; Blynk currently documents a 100-event-per-device-per-day limit under standard configurations. Blynk Docs+1
-
The actual transformer protection scheme requires electrical engineering design.
72. Future enhancements
The next version could add:
ESP32
│
├── Energy meter
├── Power factor
├── Frequency
├── Harmonic analysis
├── Vibration
├── Oil temperature
├── Oil level
├── Humidity
├── Smoke/fire sensor
└── Door/open sensor
Then:
AI
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Anomaly detection Predictive Maintenance
failure scheduling
You could eventually implement:
Predictive maintenance
Historical data
↓
Temperature trends
↓
Current trends
↓
Voltage imbalance
↓
Operating hours
↓
AI/anomaly model
↓
Maintenance recommendation
73. Final complete system
┌─────────────────────┐
│ 3-PHASE TRANSFORMER │
└──────────┬──────────┘
│
┌────────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
Voltage sensors Current sensors Temperature
VA/VB/VC IA/IB/IC sensor
│ │ │
└────────────────────────┼─────────────────────┘
▼
┌─────────────────────┐
│ ESP32 │
│ │
│ ADC │
│ RMS │
│ Filtering │
│ Fault detection │
│ Protection logic │
└──────┬──────┬───────┘
│ │
┌────────────┘ └──────────────┐
▼ ▼
LOCAL PROTECTION Wi-Fi
│ │
▼ ┌─────────────┼──────────────┐
Isolated trip │ │ │
interface ▼ ▼ ▼
ThingSpeak Blynk n8n
│ │ │
▼ ▼ ▼
Historical Mobile/Web Validation
Data Dashboard │
▼
AI Agent
│
┌───────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Gmail Telegram Google Sheets
│
┌─────┴─────┐
▼ ▼
Text Voice
Alert
74. Recommended technology stack
| Layer | Technology |
|---|---|
| Controller | ESP32 |
| Firmware | Arduino C++ |
| Voltage sensing | Isolated PT/transducer |
| Current sensing | CT/Hall transducer |
| Temperature | DS18B20 / industrial RTD |
| Local processing | ESP32 |
| Local protection | ESP32 + isolated interface + engineered protection |
| IoT cloud | ThingSpeak |
| Mobile dashboard | Blynk |
| Web dashboard | Blynk / custom web UI |
| Automation | n8n |
| AI | n8n AI Agent + selected LLM provider |
| Database/log | Google Sheets |
| Gmail | |
| Text alert | Telegram |
| Voice alert | TTS + Telegram |
| Historical analysis | ThingSpeak/Sheets |
| Security | HTTPS + credentials + webhook authentication |
75. Official technical references
-
ESP32 Arduino documentation — ESP32 Arduino APIs and ADC documentation. Espressif Systems+1
-
ThingSpeak REST API documentation — channel read/write REST API. MathWorks
-
ThingSpeak channel/data limits — current API rate-limit information. MathWorks
-
Blynk Events documentation — firmware event generation and notifications. Blynk Docs
-
Blynk notification documentation — push/email/SMS notification configuration. Blynk Docs
-
n8n documentation — automation and AI workflow platform. n8n Documentation
-
n8n Telegram node — Telegram message/audio operations. n8n Documentation
-
n8n Gmail node — automated email operations. n8n Documentation
Bottom line
The recommended final architecture is:
Sensors → ESP32 → local RMS/fault processing → local protection + Blynk + ThingSpeak → n8n → AI Agent → Google Sheets + Gmail + Telegram text + Telegram voice + Web Dashboard.
The most important design decision is to keep immediate protection deterministic and local, while using n8n/AI for diagnosis, logging, orchestration and operator notifications. That gives you a much stronger and more defensible “Agentic IoT” project than putting the protection decision in the cloud.
If you implement this as an academic prototype, use a low-voltage isolated transformer test setup rather than exposing the ESP32/sensors to hazardous mains voltage.
