IoT-Based Smart Power Grid Monitoring and Overload Protection Using ESP32, n8n, AI Agent, Telegram Voice Alerts, Google Sheets & ThingSpeak
Important safety note: If you are building this as a college/project prototype, develop and test the sensing/protection logic first using a safe low-voltage AC source or an isolated measurement module. Do not connect an ESP32 breadboard directly to 230-V mains. Actual mains protection should use appropriately rated MCB/RCCB/RCBO, fuses, contactors and certified isolation/protection hardware installed by a qualified person. The ESP32 should be an additional monitoring/control layer, not the sole safety device.
1. Project Abstract
The proposed system is an IoT-enabled smart electrical power monitoring and overload protection system based on an ESP32 microcontroller.
The ESP32 continuously measures electrical parameters such as:
- Voltage
- Current
- Power
- Energy
- Power factor, if supported by the selected energy-metering sensor
- Overload status
- Relay/contactor status
- Device/system temperature, optionally
The ESP32 sends the measurements to the cloud through Wi-Fi.
The system uses n8n as the automation/orchestration layer. n8n receives data from the ESP32 through a webhook, evaluates the electrical condition, stores the data in Google Sheets, updates cloud services such as ThingSpeak, and generates alerts.
An AI Agent can be placed inside the n8n workflow to analyze abnormal conditions and produce a human-readable explanation such as:
"Current has exceeded the configured limit continuously for 18 seconds. The load is likely overloaded. Disconnecting the load is recommended."
The alert is then sent through Telegram, optionally as a voice notification.
The overall system therefore combines:
ESP32 + IoT Sensors + Local Protection + Wi-Fi + n8n + AI Agent + Google Sheets + ThingSpeak + Telegram
into one smart monitoring platform.
2. Main Objectives
The project has eight major objectives.
Objective 1 — Real-time monitoring
Measure electrical parameters continuously.
Objective 2 — Local overload protection
The ESP32 should be capable of taking immediate protective action without waiting for the cloud.
Objective 3 — IoT connectivity
Transmit electrical measurements through Wi-Fi.
Objective 4 — Automation
Use n8n to process incoming measurements and execute actions automatically.
Objective 5 — AI-based interpretation
Use an AI Agent to convert raw sensor information into understandable diagnostics.
Objective 6 — Cloud dashboard
Display historical electrical data through ThingSpeak.
ThingSpeak provides REST and MQTT mechanisms for updating channel data and is specifically designed for collecting, visualizing and analyzing IoT data.
Objective 7 — Data logging
Store measurements and events in Google Sheets.
Objective 8 — Intelligent notification
Send Telegram text and voice notifications when an abnormal condition occurs.
3. Overall System Architecture
┌───────────────────────────┐│ ELECTRICAL LOAD ││ Motor / Lamp / Heater │└─────────────┬─────────────┘││ Electrical│ parameters▼┌───────────────────────────┐│ SENSOR SECTION ││ ││ Voltage Sensor ││ Current Sensor ││ Energy Meter / PF Sensor │└─────────────┬─────────────┘│▼┌───────────────────────────┐│ ESP32 ││ ││ ADC / Sensor Interface ││ RMS Calculation ││ Power Calculation ││ Overload Detection ││ Local Protection ││ Wi-Fi Communication │└──────┬──────────────┬─────┘│ │LOCAL │ │ Wi-FiPROTECTION ││ ▼▼ ┌───────────────┐┌─────────────┐│ n8n ││ Relay / ││ Automation ││ Contactor │└───────┬───────┘└─────────────┘ ││┌─────────────────┼──────────────────┐│ │ │▼ ▼ ▼┌────────────┐ ┌──────────────┐ ┌──────────────┐│ AI AGENT │ │ Google Sheets│ │ ThingSpeak ││ Analysis │ │ Data Logging │ │ Dashboard │└─────┬──────┘ └──────────────┘ └──────────────┘│▼┌───────────────┐│ TELEGRAM ││ Text Alert ││ Voice Alert │└───────────────┘
4. Recommended Hardware
For a prototype, the following architecture works well.
| Component | Purpose |
|---|---|
| ESP32 DevKit | Main controller |
| Current sensor / isolated energy meter | Current measurement |
| Isolated voltage measurement | Voltage measurement |
| Relay module / contactor driver | Load disconnection |
| Contactor | Higher-current load switching |
| OLED/LCD | Local display |
| Buzzer | Local alarm |
| LEDs | Status indication |
| 5-V/3.3-V regulated supply | Electronics supply |
| Wi-Fi router/hotspot | Internet connection |
| Push button | Manual reset |
| Fuse/MCB/RCCB as appropriate | Independent electrical protection |
Sensor choices
There are several ways to implement measurement.
Option A — Energy-metering module
A dedicated energy-metering module is easiest if you want:
VoltageCurrentPowerEnergyPower FactorFrequency
depending on the module.
Option B — Current transformer + voltage transformer
For a more educational design:
Current Transformer → ESP32 ADCVoltage Transformer → ESP32 ADC
The ESP32 calculates RMS voltage/current and power.
Option C — Low-voltage prototype
For the safest demonstration:
12/24-V AC source↓Voltage sensor↓Current sensor↓ESP32↓MOSFET/Relay↓Load
This is the version I recommend for the first prototype.
5. Functional Block Diagram
┌─────────────────────┐│ Electrical Source │└──────────┬──────────┘│▼┌─────────────────────┐│ Voltage Measurement │└──────────┬──────────┘││┌──────────▼──────────┐│ Current Measurement │└──────────┬──────────┘│▼┌─────────────────────┐│ ESP32 ││ ││ Sensor acquisition ││ Filtering ││ RMS calculation ││ Power calculation ││ Threshold logic ││ Wi-Fi │└──────┬────────┬─────┘│ ││ ▼│ ┌─────────────┐│ │ Relay/ ││ │ Contactor ││ └─────────────┘│▼┌─────────────────────┐│ Internet │└──────────┬──────────┘│▼┌─────────────────────┐│ n8n ││ Webhook ││ Validation ││ Filtering ││ AI Agent ││ Routing │└───┬────┬─────┬──────┘│ │ │▼ ▼ ▼Sheets ThingSpeak Telegram
6. Electrical Protection Concept
The most important design principle is:
Protection must be local.
Do not design the system like this:
Sensor↓Internet↓n8n↓AI↓Relay OFF
because Internet failure could prevent protection.
Instead:
┌───────────────┐│ ESP32 │└───────┬───────┘│┌─────────────┴─────────────┐│ │▼ ▼LOCAL PROTECTION CLOUD MONITORING│ │▼ ▼Relay/Contactor n8n│┌───────────┼──────────┐▼ ▼ ▼AI Agent Sheets Telegram
If Wi-Fi disappears:
Wi-Fi OFF↓ESP32 still measures current↓ESP32 detects overload↓ESP32 disconnects load
That is much safer.
7. Overload Algorithm
Suppose:
Rated current = 5 AWarning current = 4 ATrip current = 5 A
The logic can be:
Current < 4 A↓NORMAL4 A ≤ Current < 5 A↓WARNINGCurrent ≥ 5 A↓OVERLOAD TIMERCurrent remains ≥ 5 Afor 5 seconds↓TRIPRelay OFF↓Send event to n8n↓AI analysis↓Telegram alert
The timer is important.
You generally don't want a single noisy sensor reading to cause a trip.
8. State Machine
┌────────────┐│ NORMAL │└─────┬──────┘│Current > Warning│▼┌────────────┐│ WARNING │└─────┬──────┘│Current > Trip│▼┌─────────────────┐│ OVERLOAD TIMER │└────────┬────────┘│Timeout reached│▼┌────────────┐│ TRIPPED │└─────┬──────┘│Manual reset│▼┌────────────┐│ NORMAL │└────────────┘
9. ESP32 Software Architecture
The ESP32 program should have separate functions.
setup()│├── Initialize GPIO├── Initialize sensor├── Initialize display├── Initialize Wi-Fi└── Initialize protectionloop()│├── Read sensors├── Filter data├── Calculate electrical parameters├── Check overload├── Update relay├── Update display├── Send cloud data└── Check Wi-Fi
10. ESP32 Example Code
The following is a prototype framework. The sensor conversion constants must be calibrated against the exact sensor/module you use.
#include <WiFi.h>#include <HTTPClient.h>#include <ArduinoJson.h>// -------------------------------// Wi-Fi configuration// -------------------------------const char* WIFI_SSID = "YOUR_WIFI";const char* WIFI_PASSWORD = "YOUR_PASSWORD";// n8n webhookconst char* N8N_WEBHOOK ="https://YOUR-N8N-DOMAIN/webhook/power-monitor";// -------------------------------// GPIO// -------------------------------const int CURRENT_PIN = 34;const int VOLTAGE_PIN = 35;const int RELAY_PIN = 26;const int BUZZER_PIN = 27;const int RESET_BUTTON = 25;// -------------------------------// Protection settings// -------------------------------const float WARNING_CURRENT = 4.0;const float TRIP_CURRENT = 5.0;const unsigned long TRIP_DELAY = 5000;bool tripped = false;unsigned long overloadStart = 0;unsigned long lastUpload = 0;// -------------------------------// Measurement variables// -------------------------------float voltage = 0.0;float current = 0.0;float power = 0.0;float energy = 0.0;// -------------------------------// Connect Wi-Fi// -------------------------------void connectWiFi(){if (WiFi.status() == WL_CONNECTED)return;Serial.println("Connecting to Wi-Fi...");WiFi.begin(WIFI_SSID, WIFI_PASSWORD);unsigned long start = millis();while (WiFi.status() != WL_CONNECTED &&millis() - start < 15000){delay(500);
Why the code is structured this way
The protection logic does not depend on n8n.
The ESP32 itself performs:
measurement↓threshold comparison↓overload timer↓trip
while n8n handles:
loggingAI analysisnotificationscloud integration
11. Sensor Calibration
The example conversion:
current = currentADC * 0.010;
is intentionally only a placeholder.
Real calibration should be performed.
For example:
Known current = 1 ASensor ADC reading = XKnown current = 2 ASensor ADC reading = YKnown current = 3 ASensor ADC reading = Z
Then derive:
Current = calibration_factor × ADC + offset
For AC systems, don't simply use one ADC sample.
You normally calculate RMS from multiple samples:
N┌───Irms = │ i²└───N
or:
Irms = sqrt((i1² + i2² + ... + iN²) / N)
For a real AC power-monitoring implementation, sensor calibration and phase relationships are important.
12. Improved AC Measurement
A better architecture is:
Current Sensor│▼ADC samples│▼Remove DC offset│▼Square samples│▼Average│▼Square root│▼Irms
For voltage:
Voltage sensor↓ADC↓Offset removal↓RMS calculation↓Vrms
Then:
Apparent PowerS = Vrms × Irms
If you measure true real power:
P = average(v(t) × i(t))
Power factor:
PF = P / S
This becomes much more accurate for non-resistive loads.
13. n8n Architecture
The n8n workflow can be divided into several stages.
ESP32│▼Webhook│▼Validate Data│▼Normalize Data│▼Check Threshold│├────────────── NORMAL ────────────────┐│ ││ ▼│ Google Sheets│ ││ ▼│ ThingSpeak│└──────────── ABNORMAL ────────────────┐│▼AI Agent│▼Alert Decision│┌──────────┴──────────┐▼ ▼Telegram SheetsAlert Log│▼Voice Message
14. n8n Workflow — Node by Node
Create the following nodes.
Node 1
Webhook
Method:
POST
Path:
power-monitor
ESP32 sends:
{"device_id": "ESP32-GRID-001","voltage": 230,"current": 5.8,"power": 1334,"energy": 2.35,"overload": true,"relay": false,"wifi_rssi": -58,"uptime_ms": 1234567}
15. Node 2 — Data Validation
Use an n8n Code node.
const data = $json;if (!data.device_id) {throw new Error("Missing device_id");}if (typeof data.current !== "number") {throw new Error("Invalid current value");}if (typeof data.voltage !== "number") {throw new Error("Invalid voltage value");}return [{json: {...data,received_at: new Date().toISOString()}}];
16. Node 3 — Calculate Status
const current = Number($json.current);let status = "NORMAL";if (current >= 5.0) {status = "OVERLOAD";}else if (current >= 4.0) {status = "WARNING";}return [{json: {...$json,status}}];
17. Node 4 — IF Node
Configure:
status == OVERLOAD
Then:
TRUE → AI AgentFALSE → Normal processing
18. AI Agent Concept
The AI Agent should not directly decide electrical safety limits.
The deterministic system should determine:
current > threshold
The AI should interpret the situation.
For example:
Input
{"voltage": 231,"current": 6.2,"power": 1432,"status": "OVERLOAD","relay": false}
AI task
Ask the AI to generate:
1. Event classification2. Short explanation3. Recommended human action4. Alert severity
19. Suggested AI Agent Prompt
You are an electrical IoT monitoring assistant.Analyze the sensor information supplied by the ESP32.Important rules:1. Never override the ESP32 protection decision.2. Never instruct the system to ignore an overload.3. Treat an ESP32 trip as a protection event.4. Clearly distinguish between warning and confirmed trip.5. Do not claim that a physical fault has been diagnosed unless the sensor data supports it.6. Provide concise explanations suitable for Telegram.Return:Severity:Event:Current:Voltage:Power:Explanation:Recommended action:
20. Example AI Output
Severity: HIGHEvent: OVERLOAD TRIPCurrent: 6.2 AVoltage: 231 VPower: 1.43 kWExplanation:The measured current exceeded the configured protection threshold and the ESP32 disconnected the load.Recommended action:Inspect the connected load before resetting the protection system.
This is much better than asking an AI model to independently control a dangerous relay.
21. Google Sheets Database
Create a spreadsheet:
Smart Grid Monitoring
Columns:
| Column | Data |
|---|---|
| A | Timestamp |
| B | Device ID |
| C | Voltage |
| D | Current |
| E | Power |
| F | Energy |
| G | Status |
| H | Relay |
| I | Wi-Fi RSSI |
| J | AI Severity |
| K | AI Explanation |
| L | Event |
Example:
2026-08-20 22:15:01ESP32-GRID-0012316.214322.35OVERLOADOFF-58HIGHOverload detected...TRIP
22. ThingSpeak Configuration
Create a ThingSpeak channel.
Suggested fields:
Field 1 = VoltageField 2 = CurrentField 3 = PowerField 4 = EnergyField 5 = Power FactorField 6 = FrequencyField 7 = OverloadField 8 = Relay State
ThingSpeak accepts channel updates through its REST API, including requests to api.thingspeak.com/update; the write API key identifies the channel permission used for writing data.
Example request:
POSThttps://api.thingspeak.com/update
Parameters:
api_key = YOUR_WRITE_API_KEYfield1 = voltagefield2 = currentfield3 = powerfield4 = energyfield5 = power_factorfield6 = frequencyfield7 = overloadfield8 = relay
ThingSpeak also provides an ESP32 example involving channel updates and TalkBack commands.
23. n8n → ThingSpeak
In n8n, use an HTTP Request node.
Method:GET or POSTURL:https://api.thingspeak.com/update
Parameters:
api_key = YOUR_WRITE_KEYfield1 = {{$json.voltage}}field2 = {{$json.current}}field3 = {{$json.power}}field4 = {{$json.energy}}field7 = {{$json.overload}}field8 = {{$json.relay}}
For production, keep API keys in n8n credentials/environment variables rather than putting secrets directly into workflow logic.
24. Telegram Architecture
Telegram should have two alert levels.
Warning
⚠️ POWER WARNINGDevice: ESP32-GRID-001Current: 4.3 AVoltage: 230 VPower: 989 WCurrent is approaching the configured limit.
Trip
🚨 OVERLOAD PROTECTION TRIGGEREDDevice: ESP32-GRID-001Current: 6.2 AVoltage: 231 VPower: 1.43 kWThe ESP32 has disconnected the load.Please inspect the load before resetting.
25. Telegram Voice Alert
The workflow can be:
ESP32↓n8n↓Overload detected↓AI Agent↓Generate text↓Text-to-Speech↓Audio file↓Telegram↓Voice message
Example voice message:
"Warning. Smart grid device one has detected an overload. The measured current is 6.2 amperes. The load has been disconnected. Please inspect the load before resetting."
This gives your project a strong Agentic IoT demonstration.
26. Complete n8n Workflow
A practical workflow can look like this:
┌────────────────────┐│ ESP32 POST Request │└─────────┬──────────┘│▼┌─────────────────┐│ Webhook │└────────┬────────┘│▼┌─────────────────┐│ Validate JSON │└────────┬────────┘│▼┌─────────────────┐│ Normalize Data │└────────┬────────┘│▼┌─────────────────┐│ Calculate State │└────────┬────────┘│┌─────┴─────┐│ │NORMAL ALERT│ ││ ▼│ ┌──────────┐│ │ AI Agent ││ └────┬─────┘│ ││ ▼│ ┌────────────┐│ │ TTS Engine ││ └─────┬──────┘│ ││ ▼│ ┌────────────┐│ │ Telegram ││ └────────────┘│└─────────┬──────────┐│ │▼ ▼Google Sheets ThingSpeak
27. Agentic IoT Concept
The project becomes more interesting when you describe the system as Agentic IoT.
Traditional IoT:
Sensor↓Cloud↓Dashboard
Your architecture:
Sensor↓ESP32↓Event detection↓n8n↓AI Agent↓Reasoning / interpretation↓Automated communication↓Human
The AI isn't responsible for the hard protection decision.
Instead:
ESP32 = deterministic safety/controln8n = orchestrationAI = interpretationTelegram = human notificationSheets = recordThingSpeak = visualization
This separation is an excellent design decision for your project.
28. Complete Data Flow
ELECTRICAL SYSTEM│▼┌─────────────────┐│ Voltage Sensor │└────────┬────────┘│┌────────▼────────┐│ Current Sensor │└────────┬────────┘│▼┌───────────┐│ ESP32 │└─────┬─────┘│┌────────┴─────────┐│ │▼ ▼Protection Wi-Fi Data│ │▼ ▼Contactor n8n│┌───────────┼────────────┐│ │ │▼ ▼ ▼Sheets ThingSpeak AI Agent│▼Alert Decision│▼Telegram│┌────────┴────────┐▼ ▼Message Voice
29. Protection Circuit Concept
For the low-voltage prototype, the concept can be:
+V││┌───┴────┐│ LOAD │└───┬────┘│Relay Contact││GND
Control:
ESP32 GPIO 26│▼Relay Driver│▼Relay/Contactor│▼Load
For a higher-power AC installation:
SUPPLY│▼MCB/RCCB/etc.│▼Contactor│▼LOAD│▼RETURN
The ESP32 controls the contactor coil through an appropriately rated isolated driver, not the mains load directly.
30. Suggested Wiring Table
For the prototype:
| ESP32 | Component |
|---|---|
| GPIO 34 | Current sensor output |
| GPIO 35 | Voltage sensor output |
| GPIO 26 | Relay driver |
| GPIO 27 | Buzzer |
| GPIO 25 | Reset button |
| 3.3 V | Sensor logic supply where appropriate |
| GND | Common low-voltage reference |
Do not assume every sensor is 3.3-V compatible. Verify the exact sensor/module electrical specifications before connecting it to an ESP32 ADC.
31. LED Status System
Add three LEDs:
GREEN = NORMALYELLOW = WARNINGRED = TRIPPED
State:
NORMALGreen ONYellow OFFRed OFF
Warning:
Green OFFYellow ONRed OFF
Trip:
Green OFFYellow OFFRed ONBuzzer ONRelay OFF
32. OLED Display
The local display can show:
SMART GRID----------------V : 231.2 VI : 3.82 AP : 882 WE : 2.31 kWhSTATUS: NORMAL
During overload:
!!! OVERLOAD !!!V : 231.1 VI : 6.21 AP : 1434 WRELAY: OFF
This makes the physical prototype much easier to demonstrate.
33. Fault Scenarios
Your project should demonstrate at least these cases.
Case 1 — Normal
Current = 2.5 AESP32:NORMALRelay:ONn8n:Log dataTelegram:No alert
Case 2 — Warning
Current = 4.3 AESP32:WARNINGRelay:ONn8n:Log eventTelegram:Warning notification
Case 3 — Overload
Current = 6.2 AESP32:OVERLOADRelay:OFFn8n:AI analysisTelegram:Text + voice alertSheets:Event loggedThingSpeak:Data recorded
Case 4 — Internet failure
Wi-Fi OFFESP32:Continues monitoringOverload:Detected locallyRelay:OFFCloud:UnavailableProtection:Still works
This is an important test.
34. Failure-Mode Analysis
| Failure | Required behavior |
|---|---|
| Wi-Fi failure | Local protection continues |
| n8n unavailable | Local protection continues |
| Telegram unavailable | Event remains locally/cloud logged when possible |
| AI unavailable | Deterministic protection still works |
| Sensor disconnected | Detect invalid measurement |
| Sensor reading impossible | Fail-safe behavior |
| ESP32 reboot | Protection state should be explicitly defined |
| Relay failure | Detect using feedback if possible |
| Power failure | Hardware protection remains independent |
35. Sensor-Failure Protection
A sophisticated version should detect impossible values.
For example:
Voltage = -500 V
or:
Current = NaN
or:
Current suddenly changes:1.2 A1.3 A1.1 A57 A1.2 A
The system should recognize:
Sensor anomaly
instead of blindly treating it as a genuine load condition.
36. Watchdog
Add an ESP32 watchdog or equivalent fault-recovery mechanism.
Conceptually:
ESP32 running↓Watchdog timer↓Software hangs?↓YES↓Restart
But the relay state after reboot must be deliberately designed. For a protection system, "what happens after restart?" is a safety decision, not just a programming detail.
37. Security Architecture
Do not expose an unauthenticated webhook publicly if avoidable.
Instead:
ESP32↓HTTPS↓Authenticated n8n webhook
Use:
- HTTPS
- webhook authentication
- secret tokens
- API keys stored securely
- restricted Telegram bot permissions
- private ThingSpeak channel where appropriate
Do not put:
Wi-Fi passwordThingSpeak API keyTelegram bot tokenAI API key
into publicly shared source code.
38. Better ESP32 → n8n JSON
I recommend using a structured payload:
{"device": {"id": "ESP32-GRID-001","firmware": "1.0.0"},"measurement": {"voltage": 231.2,"current": 6.21,"power": 1435.0,"energy": 2.35,"frequency": 50.0,"power_factor": 0.97},"protection": {"warning": true,"overload": true,"tripped": true,"relay": false},"network": {"rssi": -58}}
This is easier to expand later.
39. Example n8n AI Input
The AI node can receive:
{"device_id": "ESP32-GRID-001","voltage": 231.2,"current": 6.21,"power": 1435,"status": "OVERLOAD","relay": false,"duration": 18}
AI output:
{"severity": "HIGH","event": "OVERLOAD_TRIP","message":"Current exceeded the configured limit for 18 seconds. The ESP32 disconnected the load.","recommended_action":"Inspect the connected load before resetting."}
Structured AI output makes downstream n8n processing much easier.
40. Telegram Workflow
AI Agent│▼Structured Output│▼IF severity == HIGH│├───────────────┐▼ ▼Telegram Text Text-to-Speech│▼Audio│▼Telegram Voice
You can send both:
🚨 Text notification
and:
🔊 Voice notification
41. Example Telegram Conversation
System:
🚨 SMART GRID ALERTDevice: ESP32-GRID-001Voltage: 231.2 VCurrent: 6.21 APower: 1.44 kWStatus: OVERLOADRelay: OFFAI Analysis:The configured current limit was exceededcontinuously and the ESP32 disconnected the load.Action:Inspect the load before resetting.
User:
/status
Bot:
SMART GRID STATUSVoltage: 230.8 VCurrent: 0.0 APower: 0 WRelay: OFFProtection: TRIPPEDReason:Previous overload event.Manual reset required.
42. Optional Telegram Commands
You can extend the project with:
/status/voltage/current/power/energy/history/reset/help
However, commands such as /reset should be carefully protected and should not bypass physical safety conditions.
A better design is:
/reset↓Check safety conditions↓Ask for confirmation↓Permit reset only when appropriate
43. AI Agent Extended Capabilities
Once the basic system works, the AI Agent can perform:
Anomaly explanation
"Current increased 72% in the last 30 seconds."
Pattern analysis
"High consumption is occurring repeatedly between 18:00 and 20:00."
Maintenance suggestion
"Repeated overload events suggest the load may be exceeding its intended rating."
Natural-language reporting
"Today's peak power was 2.8 kW at 7:42 PM."
But again:
AI interprets; deterministic protection protects.
44. Smart Energy Dashboard
ThingSpeak can provide graphs such as:
Current vs TimeA7 | *6 | *5 | * *4 | * *3 | * *2 | * *1 |________________Time
Voltage:
Voltage vs TimeV240 | *235 | * * *230 |************225 |220 |________________
Power:
Power vs TimeW2000 | *1500 | **1000 | ****500 | **0 |________________
45. Google Sheets Dashboard
You can create:
┌──────────────────────────────────┐│ SMART GRID MONITORING │├──────────────────────────────────┤│ Voltage 231.2 V ││ Current 3.8 A ││ Power 880 W ││ Energy 2.35 kWh ││ Status NORMAL ││ Relay ON │├──────────────────────────────────┤│ Today's Events: 3 ││ Overloads: 1 ││ Warnings: 2 │└──────────────────────────────────┘
46. Complete Project Flow
START│▼Initialize ESP32│▼Connect Wi-Fi│▼Read Voltage│▼Read Current│▼Calculate Power/Energy│▼Validate Sensor Data│▼Current > Warning?│┌┴───────────────┐NO YES│ │▼ ▼NORMAL WARNING│ ││ Current > Trip?│ ││ ┌──┴──┐│ NO YES│ │ ││ ▼ ▼│ WARNING START TIMER│ ││ Timer Expired?│ ││ ┌──┴──┐│ NO YES│ │ ││ ▼ ▼│ Continue TRIP│ ││ ▼│ Relay OFF│ │└──────────────┬───────────┘│▼Send data to n8n│▼Store in Sheets│▼Update ThingSpeak│▼Abnormal event?│ │NO YES│ ││ ▼│ AI Agent│ ││ ▼│ Generate Alert│ ││ ▼│ Telegram│ ││ ▼│ Voice Notification│▼Repeat
47. Recommended Project Folder Structure
SmartGrid-IoT/│├── ESP32/│ ├── SmartGrid.ino│ ├── config.h│ ├── sensors.h│ ├── protection.h│ └── communication.h│├── n8n/│ ├── workflow.json│ ├── prompts/│ │ └── overload-agent.txt│ └── README.md│├── documentation/│ ├── project-report.md│ ├── block-diagram.png│ ├── circuit-diagram.png│ ├── flowchart.png│ └── test-results.xlsx│├── dashboard/│ └── thingspeak.md│└── README.md
48. Suggested Project Report Chapters
For a college/final-year project report, use:
Chapter 1 — Introduction
- Background
- Problem statement
- Motivation
- Objectives
- Scope
Chapter 2 — Literature/Technology Review
- IoT
- ESP32
- Smart grids
- Energy monitoring
- AI agents
- Workflow automation
- Cloud monitoring
Chapter 3 — Proposed System
- Architecture
- Hardware
- Software
- Communication
Chapter 4 — Hardware Design
- ESP32
- Sensors
- Relay/contactor
- Display
- Buzzer
- Power supply
Chapter 5 — Software Design
- ESP32 firmware
- Wi-Fi
- HTTP
- n8n
- AI Agent
- Telegram
- Google Sheets
- ThingSpeak
Chapter 6 — Implementation
- Circuit
- Firmware
- n8n workflow
- Cloud configuration
Chapter 7 — Testing
- Normal load
- Warning condition
- Overload
- Wi-Fi failure
- Sensor failure
- Recovery
Chapter 8 — Results
- Tables
- Graphs
- Screenshots
- Telegram alerts
- ThingSpeak graphs
Chapter 9 — Advantages and Limitations
Chapter 10 — Future Scope
Chapter 11 — Conclusion
49. Testing Table
| Test | Input | Expected result |
|---|---|---|
| Normal | 2 A | Relay ON |
| Warning | 4.2 A | Warning |
| Overload | 5.5 A | Timer starts |
| Sustained overload | 5.5 A > 5 s | Relay OFF |
| Short spike | 5.5 A < 1 s | No trip |
| Wi-Fi failure | Wi-Fi OFF | Local protection works |
| n8n failure | Server unavailable | Local protection works |
| Reset | Safe condition | Relay can recover |
| Sensor fault | Invalid signal | Fault state |
50. Performance Metrics
You can measure:
Detection time
Detection time =Trip command time - threshold crossing time
Notification latency
Notification latency =Telegram arrival - ESP32 event time
Cloud latency
Cloud latency =ThingSpeak timestamp - sensor timestamp
Accuracy
Compare:
Reference metervsESP32 measurement
Calculate:
Error (%) =|Reference - Measured|---------------------- × 100Reference
51. Important Design Improvement — Don't Make the AI the Protection System
This point is worth emphasizing in your project viva.
If the examiner asks:
"Why do you need AI if the ESP32 can detect overload?"
Answer:
"The ESP32 performs deterministic protection because protection should not depend on an Internet connection or probabilistic AI output. The AI Agent is used for higher-level interpretation, anomaly explanation, event summarization and intelligent notification."
That is a strong engineering answer.
52. Why n8n?
n8n acts as the central automation layer:
ESP32↓n8n├── Google Sheets├── ThingSpeak├── AI├── Telegram├── TTS└── Future services
Without n8n, you would have to implement many independent APIs directly inside the ESP32.
With n8n:
ESP32 firmware remains relatively simple
while cloud integrations can be changed without reflashing the ESP32.
53. Why ESP32?
ESP32 is suitable because it provides:
- Wi-Fi
- GPIO
- ADC
- multiple communication interfaces
- sufficient processing capability for sensor processing
- low cost
- large development ecosystem
The ESP32 therefore serves as the edge computing device.
54. Why ThingSpeak?
ThingSpeak is useful for:
Data collection+Time-series visualization+Cloud storage+IoT analytics
Its REST API supports updating fields in a channel, while its documentation also describes MQTT and other IoT mechanisms.
55. Why Google Sheets?
Google Sheets provides:
Simple database+Human-readable records+Event history+Easy reporting+Export to Excel/CSV
This is especially useful for a student project because the examiner can inspect actual historical measurements.
56. Why Telegram?
Telegram provides:
Instant notification+Mobile access+Bot interface+Text alerts+Voice/audio notifications+Commands
This allows the electrical monitoring system to become a practical remote-monitoring system rather than just a laboratory display.
57. Future Expansion
The project can eventually become a multi-node smart-grid system.
┌──────────────┐│ n8n/Cloud │└───────┬──────┘│┌─────────────┼─────────────┐│ │ │▼ ▼ ▼ESP32-01 ESP32-02 ESP32-03House A House B Factory│ │ │▼ ▼ ▼Load A Load B Load C
Each ESP32 can have:
device_idlocationvoltagecurrentpowerenergystatus
The AI Agent can then compare different nodes.
58. Advanced Version
A future architecture could be:
SMART GRID CLOUD│┌─────────┴─────────┐│ n8n ││ Automation Engine │└─────────┬─────────┘│AI AGENT│┌────────────┼────────────┐│ │ │Analytics Prediction Alerts│ │ │└────────────┼────────────┘│ESP32 NETWORK│┌───────────────┼──────────────┐│ │ │NODE 1 NODE 2 NODE 3│ │ │LOAD A LOAD B LOAD C
Potential future features:
- load forecasting
- anomaly detection
- predictive maintenance
- peak-load prediction
- automatic load prioritization
- solar monitoring
- battery monitoring
- EV charging monitoring
- smart building energy management
59. Final System Architecture
The final project can be presented as five layers:
╔══════════════════════════════════════════════╗║ LAYER 5 — USER ║║ Telegram / Dashboard / Reports ║╚══════════════════════════════════════════════╝▲│╔══════════════════════════════════════════════╗║ LAYER 4 — INTELLIGENCE ║║ AI Agent / Anomaly Explanation ║╚══════════════════════════════════════════════╝▲│╔══════════════════════════════════════════════╗║ LAYER 3 — AUTOMATION ║║ n8n / APIs / Google Sheets ║╚══════════════════════════════════════════════╝▲│╔══════════════════════════════════════════════╗║ LAYER 2 — NETWORK ║║ Wi-Fi / Internet ║╚══════════════════════════════════════════════╝▲│╔══════════════════════════════════════════════╗║ LAYER 1 — EDGE DEVICE ║║ ESP32 / Sensors / Local Protection / Relay ║╚══════════════════════════════════════════════╝▲│ELECTRICAL LOAD
60. One-Line Project Definition
You can describe the project in your presentation as:
"An edge-first IoT smart power monitoring and overload protection system in which ESP32 performs real-time electrical measurement and local protection, n8n orchestrates cloud automation, an AI Agent interprets abnormal events, ThingSpeak visualizes electrical data, Google Sheets maintains event history, and Telegram provides real-time text and voice notifications."
Recommended implementation order
Don't try to build everything simultaneously. Build it in this order:
1. ESP32 + sensor↓2. Accurate voltage/current measurement↓3. Local overload detection↓4. Relay/contactor control↓5. ESP32 Wi-Fi↓6. ESP32 → n8n webhook↓7. n8n → Google Sheets↓8. n8n → ThingSpeak↓9. n8n → Telegram text↓10. AI Agent↓11. Text-to-Speech↓12. Telegram voice↓13. Dashboard↓14. Fault testing↓15. Final enclosure and presentation
This gives you a robust ESP32 + n8n + AI Agentic IoT project rather than a system where the AI is unnecessarily placed in the electrical safety path.
For the ThingSpeak portion, the official documentation confirms that channel data can be written through REST and that API keys control write access.
If you are using 230-V Indian mains, keep the ESP32/sensor electronics galvanically isolated from hazardous conductors and retain conventional electrical protection independently of this IoT system.
No comments:
Post a Comment