SVSEmbedded will do new innovative thoughts. Any latest idea will comes we will take that idea & implement that idea in a few days. We always encourage the students to take good ideas/projects.
SVSEmbedded providing latest innovative electronics projects to B.E/B.Tech/M.E/M.Tech students. We developed thousands of projects for engineering student to develop their skills in electrical and electronics
AI/TTS — converts the alert into a spoken Telegram voice message
The ESP32 performs the measurement and fast local safety decision. n8n and the AI agent should be considered the supervisory/notification layer—not the primary electrical safety mechanism.
2. Important safety architecture
If you are monitoring 230-V AC mains, do not connect mains directly to an ESP32 ADC.
Use an appropriately rated, isolated sensing module such as:
isolated AC voltage sensor/transducer
isolated current transformer (CT)
Hall-effect current sensor with suitable isolation
certified energy-metering module
The ESP32 ADC must only receive a safe low-voltage signal.
For a real installation, the load-disconnection device should be an appropriately rated contactor/relay with proper isolation, fuse/MCB/RCD protection and enclosure. Software must never be relied upon as the only protection against electrical faults.
The ESP32 ADC has finite input ranges and attenuation settings; Espressif's documentation specifically recommends configuring attenuation and calibration for accurate measurements.
A CT should normally measure one conductor, not both live and neutral together, otherwise their magnetic fields can cancel.
6. Suggested ESP32 pin configuration
For a conventional ESP32 DevKit:
Voltage sensor → GPIO34
Current sensor → GPIO35
Green LED → GPIO25
Red LED → GPIO26
Buzzer → GPIO27
Relay control → GPIO14
GND → Common low-voltage GND
GPIO34 and GPIO35 are useful ADC inputs on classic ESP32 boards.
Do not blindly copy GPIO assignments to an ESP32-C3/S3/etc.; ADC availability differs by ESP32 family. Espressif documents ADC channels and capabilities separately for the different chips.
7. Electrical measurement principle
Voltage RMS
For sampled AC voltage:
VRMS=N1i=1∑N(Vi−Voffset)2
Current RMS
IRMS=N1i=1∑N(Ii−Ioffset)2
Apparent power
S=VRMS×IRMS
where:
S = VA
V = volts
I = amps
Real power
For AC loads with non-unity power factor:
P=VRMS×IRMS×PF
For a simple resistive load:
PF≈1
Therefore:
P≈VRMS×IRMS
For accurate real power, sample voltage and current simultaneously and calculate:
P=N1i=1∑Nviii
This is preferable to simply multiplying two independently calculated RMS values.
8. Intelligent overload detection
Do not make the AI responsible for the actual overload trip.
The ESP32 should have deterministic thresholds.
Example:
Rated current = 10 A
Warning threshold = 8 A
Overload threshold = 10 A
Critical threshold = 12 A
Logic:
Current < 8 A
│
▼
NORMAL
8 A ≤ Current < 10 A
│
▼
WARNING
10 A ≤ Current < 12 A
│
▼
OVERLOAD
Current ≥ 12 A
│
▼
CRITICAL
│
├── Buzzer ON
├── Red LED ON
├── Local trip if configured
└── Send emergency event
You should also use time persistence so that a short sensor spike doesn't cause a nuisance trip.
Example:
Current > 10 A
│
▼
Start timer
│
▼
Still > 10 A after 3 seconds?
│
┌──┴──┐
NO YES
│ │
Normal OVERLOAD
9. Intelligent anomaly detection
You can go beyond simple threshold detection.
For example, calculate a rolling baseline:
Average current
Maximum current
Minimum current
Standard deviation
Rate of change
Overload duration
Voltage deviation
Power factor
Then classify:
Voltage normal + current normal
↓
NORMAL
Voltage low + current high
↓
POSSIBLE MOTOR/LOAD ISSUE
Voltage normal + current suddenly high
↓
POSSIBLE OVERLOAD
Voltage unstable + current unstable
↓
POSSIBLE SUPPLY PROBLEM
Current remains high for long duration
↓
THERMAL RISK
The AI agent can then explain the event in human-readable language.
10. ESP32 software architecture
setup()
│
├── Serial
├── GPIO
├── ADC
├── Wi-Fi
└── time synchronization
│
▼
loop()
│
├── Sample voltage
├── Sample current
├── Calculate RMS
├── Calculate power
├── Detect overload
├── Update LEDs/buzzer
├── Send cloud data
└── Repeat
11. ESP32 Arduino code
The following is a prototype/reference implementation. The voltage/current conversion constants must be calibrated against your actual sensors.
#include <WiFi.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>
#include <math.h>
// =============================
// Wi-Fi
// =============================
const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASSWORD = "YOUR_PASSWORD";
// n8n webhook
const char* N8N_WEBHOOK =
"https://YOUR-N8N-DOMAIN/webhook/esp32-energy";
// ThingSpeak
const char* THINGSPEAK_API_KEY =
"YOUR_THINGSPEAK_WRITE_KEY";
// =============================
// GPIO
// =============================
const int VOLTAGE_PIN = 34;
const int CURRENT_PIN = 35;
const int GREEN_LED = 25;
const int RED_LED = 26;
const int BUZZER = 27;
const int RELAY_PIN = 14;
// =============================
// Configuration
// =============================
const float RATED_CURRENT = 10.0;
const float CURRENT_WARNING = 8.0;
const float CURRENT_OVERLOAD = 10.0;
const float CURRENT_CRITICAL = 12.0;
// Sampling
const int SAMPLE_COUNT = 1000;
// Calibration constants
// MUST be calibrated with your hardware.
float voltageCalibration = 230.0;
float currentCalibration = 10.0;
// Send interval
unsigned long lastCloudSend = 0;
const unsigned long CLOUD_INTERVAL = 20000;
// Overload persistence
unsigned long overloadStart = 0;
bool overloadActive = false;
// =============================
// Wi-Fi
// =============================
void connectWiFi()
{
Important
The voltageCalibration and currentCalibration values above are illustrative, not universal sensor constants.
The correct calibration process is:
Known reference meter
│
▼
Measure actual voltage/current
│
▼
Compare ESP32 reading
│
▼
Calculate correction factor
│
▼
Update calibration coefficient
│
▼
Repeat until acceptable accuracy
Espressif notes that raw ADC results are not inherently calibrated and provides calibrated millivolt reading APIs; ADC attenuation and chip-specific characteristics also matter.
12. ThingSpeak configuration
Create a ThingSpeak channel.
Use fields such as:
Channel Name:
AI Energy Monitor
Field 1:
Voltage
Field 2:
Current
Field 3:
Power
Field 4:
Status
Field 5:
Power Factor
Field 6:
Energy
Field 7:
Temperature
Field 8:
Device Status
ThingSpeak channels support up to eight fields.
The REST API supports writing channel data using HTTP GET or POST.
For example:
https://api.thingspeak.com/update
with:
api_key=YOUR_WRITE_KEY
field1=230
field2=5.2
field3=1196
Keep the ThingSpeak write key secret. ThingSpeak documents the write API key as the credential used to update a channel.
Also account for ThingSpeak update-rate limits. The current documentation states that free licenses can update every 15 seconds, while paid licenses can update more frequently.
13. n8n architecture
Create the following workflow:
┌───────────────┐
│ Webhook │
│ ESP32 DATA │
└───────┬───────┘
│
▼
┌───────────────┐
│ Validate Data │
└───────┬───────┘
│
▼
┌───────────────┐
│ Google Sheets │
│ Append Row │
└───────┬───────┘
│
▼
┌───────────────┐
│ IF Node │
│ Status? │
└───────┬───────┘
│
┌─────────┴─────────┐
│ │
NORMAL ALERT
│ │
│ ▼
│ ┌─────────────┐
│ │ AI Agent │
│ └──────┬──────┘
│ │
│ ┌──────┴──────┐
│ │ │
│ ▼ ▼
│ Explanation Recommendation
│ │ │
│ └──────┬──────┘
│ │
│ ▼
│ ┌─────────────┐
│ │ TTS │
│ │ AI Voice │
│ └──────┬──────┘
│ │
│ ┌──────┴──────┐
│ ▼ ▼
│ Telegram Text Telegram Voice
│
└──────────────────────────────
n8n provides native Webhook, Telegram, Google Sheets and AI Agent functionality.
14. n8n Webhook node
Create:
Node:
Webhook
HTTP Method:
POST
Path:
esp32-energy
Response:
Immediately
Your ESP32 then sends:
{
"device_id": "ESP32-ENERGY-001",
"voltage": 230.4,
"current": 11.8,
"power_va": 2718.72,
"status": "OVERLOAD",
"uptime_ms": 1234567,
"wifi_rssi": -58
}
The n8n Webhook node is designed to expose an HTTP endpoint that can receive external events and trigger a workflow.
15. n8n data validation
Add a Code node.
const d = $json;
const voltage = Number(d.voltage);
const current = Number(d.current);
const power = Number(d.power_va);
if (!Number.isFinite(voltage)) {
throw new Error("Invalid voltage");
}
if (!Number.isFinite(current)) {
throw new Error("Invalid current");
}
if (!Number.isFinite(power)) {
throw new Error("Invalid power");
}
let severity = "NORMAL";
if (current >= 12) {
severity = "CRITICAL";
}
else if (current >= 10) {
severity = "OVERLOAD";
}
else if (current >= 8) {
severity = "WARNING";
}
return [{
json: {
...d,
voltage,
current,
power,
severity,
timestamp: new Date().toISOString()
}
}];
16. Google Sheets database
Create:
Sheet:
EnergyData
Columns:
Timestamp
Device ID
Voltage
Current
Power
Status
Severity
WiFi RSSI
AI Diagnosis
AI Recommendation
Alert Sent
Example:
Timestamp
Voltage
Current
Power
Status
Severity
23:00
231.2
4.2
971
NORMAL
NORMAL
23:01
230.8
8.4
1938
WARNING
WARNING
23:02
229.9
10.8
2483
OVERLOAD
OVERLOAD
n8n's Google Sheets node supports spreadsheet/document operations, making it suitable for appending measurement records to a project log.
17. AI Agent design
The AI agent should not directly decide whether the electrical system is safe.
Instead:
ESP32
│
├── deterministic safety threshold
│
└── event data
│
▼
n8n
│
▼
AI Agent
│
├── Explain event
├── Identify likely cause
├── Assess severity
└── Recommend action
This makes the architecture safer.
n8n's AI Agent node is designed to connect a chat model with tools and allow the agent to decide which tools to use.
18. AI Agent system prompt
Use a prompt similar to:
You are an industrial IoT electrical monitoring assistant.
You receive measurements from an ESP32 electrical monitoring device.
Your job is to analyze the measurements and explain abnormal conditions clearly.
Inputs:
Voltage: {{ $json.voltage }} V
Current: {{ $json.current }} A
Power: {{ $json.power }} VA
Status: {{ $json.status }}
Severity: {{ $json.severity }}
Device: {{ $json.device_id }}
Rules:
1. Never claim that the electrical system is safe based only on AI analysis.
2. Never override the ESP32 protection logic.
3. Never instruct the user to bypass electrical protection.
4. If current exceeds the configured limit, clearly identify an overload.
5. Explain possible causes.
6. Recommend safe inspection by a qualified person when appropriate.
7. Keep emergency messages short.
8. Do not invent measurements.
9. Use only the supplied sensor values.
10. Return:
- Severity
- Diagnosis
- Possible causes
- Recommended action
- Short Telegram alert
- Voice alert script
The ESP32 remains the primary real-time protection controller.
19. Example AI output
Input:
Voltage = 229.7 V
Current = 11.4 A
Power = 2611 VA
Limit = 10 A
AI response:
Severity: HIGH
Diagnosis:
The monitored load is drawing approximately 11.4 A,
which exceeds the configured 10 A continuous-current limit.
Possible causes:
1. Excessive connected load.
2. Motor startup or abnormal motor operation.
3. Faulty appliance.
4. Wiring or load-side problem.
Recommended action:
Reduce the load and inspect the connected equipment.
If the condition persists, have the electrical installation
checked by a qualified technician.
Telegram:
⚠️ OVERLOAD DETECTED
Current: 11.4 A
Limit: 10 A
Power: 2.61 kVA
Please reduce the load and inspect the equipment.
20. Telegram alert
n8n Telegram node:
Resource:
Message
Operation:
Send Message
Chat ID:
YOUR_CHAT_ID
Message:
⚠️ ELECTRICAL ALERT
Device: ESP32-ENERGY-001
Voltage: 229.7 V
Current: 11.4 A
Power: 2.61 kVA
Status: OVERLOAD
Severity: HIGH
AI Diagnosis:
The load is exceeding the configured current limit.
Recommended Action:
Reduce the load and inspect connected equipment.
n8n has a native Telegram node for Telegram operations, and Telegram's Bot API provides methods for sending messages and voice messages.
21. Telegram voice alert
This is one of the most impressive parts of the project.
Flow:
ESP32
│
▼
n8n
│
▼
AI Agent
│
▼
Voice Script
│
▼
Text-to-Speech
│
▼
MP3/OGG/M4A
│
▼
Telegram Bot
│
▼
📱 Voice Message
OpenAI's current audio API provides a speech endpoint that generates audio from text and supports formats including MP3, Opus, AAC, FLAC, WAV and PCM.
Telegram's sendVoice API accepts OGG/Opus, MP3 or M4A voice messages.
Therefore, a simple implementation is:
AI Agent
↓
"Warning. Electrical overload detected.
Current is 11.4 amperes.
Please reduce the load."
↓
OpenAI TTS
↓
MP3
↓
Telegram sendVoice
22. OpenAI TTS HTTP Request
In n8n, use an HTTP Request node.
Method:
POST
URL:
https://api.openai.com/v1/audio/speech
Headers:
Authorization:
Bearer YOUR_OPENAI_API_KEY
Content-Type:
application/json
Body:
{
"model": "gpt-4o-mini-tts",
"voice": "alloy",
"input": "Warning. Electrical overload detected. Current is 11.4 amperes. Please reduce the load and inspect the connected equipment.",
"response_format": "mp3"
}
The current OpenAI API reference documents POST /v1/audio/speech, its text input, TTS models, voices and audio output formats.
23. Telegram voice workflow
┌───────────────┐
│ AI Agent │
└───────┬───────┘
│
▼
Voice Alert Text
│
▼
┌───────────────┐
│ HTTP Request │
│ OpenAI TTS │
└───────┬───────┘
│
▼
MP3
│
▼
┌───────────────┐
│ Telegram │
│ Send Voice │
└───────┬───────┘
│
▼
📱 User Phone
Telegram's current Bot API documentation states that sendVoice can send MP3/M4A or OGG/Opus voice messages.
24. Intelligent alert suppression
A major improvement is preventing Telegram spam.
Without suppression:
10.1 A
10.2 A
10.3 A
10.4 A
10.5 A
...
could produce hundreds of messages.
Instead:
NORMAL
↓
OVERLOAD
↓
Send alert
↓
Wait
↓
Still overload?
│
├── YES → no repeated alert
│
└── NO
↓
NORMAL
↓
Send recovery
Example:
ALERT POLICY
First overload:
Send Telegram + Voice
After 5 minutes:
If still overloaded → send reminder
Recovery:
Send "System returned to normal"
25. n8n alert decision logic
Measurement
│
▼
Current >= 12 A?
/ \
YES NO
│ │
▼ ▼
CRITICAL Current >= 10 A?
/ \
YES NO
│ │
▼ ▼
OVERLOAD Current >= 8?
/ \
YES NO
│ │
▼ ▼
WARNING NORMAL
26. Recovery notification
When current returns below the warning level:
✅ ELECTRICAL SYSTEM RECOVERED
Device:
ESP32-ENERGY-001
Current:
4.7 A
Voltage:
231.1 V
Power:
1085 VA
Status:
NORMAL
The previously detected overload condition
is no longer present.
Again, this is a notification, not a guarantee that the physical installation is safe.
The dashboard can retrieve ThingSpeak data through its REST API; ThingSpeak supports reading channel data and individual fields over HTTP.
28. Webpage architecture
Internet
│
┌──────────┴───────────┐
│ │
▼ ▼
ThingSpeak n8n
│ │
│ ▼
│ AI Analysis
│ │
└──────────┬───────────┘
│
▼
Web Browser
│
┌───────┴────────┐
│ │
▼ ▼
Charts AI Status
29. Suggested web UI
Use cards:
Voltage
230.4 V
NORMAL
Current
4.72 A
NORMAL
Power
1087 W
NORMAL
System
ONLINE
And a large alert card:
┌─────────────────────────────────┐
│ ⚠️ OVERLOAD │
│ │
│ Current: 11.4 A │
│ Limit: 10.0 A │
│ │
│ AI Analysis │
│ Excessive load detected. │
│ │
│ [View Details] │
└─────────────────────────────────┘
30. Complete n8n workflow
I recommend actually creating three workflows, rather than putting everything into one giant workflow.
Workflow 1 — Measurement Logger
Webhook
↓
Validate
↓
Normalize Data
↓
Google Sheets
↓
ThingSpeak
Purpose:
Continuous data logging
Workflow 2 — AI Safety Alert
Webhook
↓
Validate
↓
IF abnormal?
↓
AI Agent
↓
Generate diagnosis
↓
Telegram text
↓
TTS
↓
Telegram voice
Purpose:
Intelligent event handling
Workflow 3 — Telegram AI Assistant
This makes the project genuinely agentic.
Telegram User
│
▼
Telegram Trigger
│
▼
AI Agent
│
├──────────────┐
│ │
▼ ▼
ThingSpeak Google Sheets
Tool Tool
│ │
└──────┬───────┘
▼
AI Response
│
▼
Telegram
n8n supports Telegram triggers as well as its AI Agent architecture.
31. Telegram AI commands
You can make the bot understand:
/status
Response:
Current status:
Voltage: 230.7 V
Current: 5.1 A
Power: 1.18 kVA
Status: NORMAL
User:
Why did the system alert me?
AI:
The system generated an overload alert because
the current exceeded the configured 10 A threshold.
The peak recorded current was 11.4 A.
User:
What happened in the last hour?
AI:
During the last hour:
Average voltage: 230.9 V
Average current: 5.2 A
Maximum current: 11.4 A
Overload events: 1
Warning events: 3
User:
Is the load currently normal?
AI:
The latest available measurement reports:
Voltage: 231.0 V
Current: 4.8 A
Status: NORMAL
No current overload is reported by the monitoring system.
32. Agent tools
Give the AI Agent tools such as:
Tool 1:
Get latest sensor data
Tool 2:
Get historical data
Tool 3:
Get last overload event
Tool 4:
Get today's maximum current
Tool 5:
Get today's energy consumption
Tool 6:
Send Telegram notification
Tool 7:
Generate voice alert
Architecture:
AI AGENT
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Latest Data Historical Alert Tool
│ │ │
▼ ▼ ▼
ThingSpeak Google Sheet Telegram
This is much closer to an agentic IoT system than simply calling an LLM after every sensor reading.
33. AI agent example
User:
Why did my ESP32 send an overload alert?
Agent:
I'll check the latest measurements and recent history.
Agent calls:
get_latest_measurement()
returns:
{
"voltage": 229.8,
"current": 11.4,
"power": 2620,
"status": "OVERLOAD"
}
Agent calls:
get_recent_history()
returns:
Average current: 5.1 A
Peak current: 11.4 A
Duration: 4 minutes
AI responds:
The overload alert was triggered because the current
reached 11.4 A, above the configured 10 A threshold.
The current remained elevated for several minutes,
so this does not appear to be only a momentary spike.
Possible causes include excessive load or abnormal
operation of one of the connected appliances.
I recommend reducing the load and having the equipment
checked if the condition returns.
34. Intelligent overload algorithm
A better algorithm than a simple threshold is:
Read current
│
▼
Moving average
│
▼
Remove noise/spikes
│
▼
Compare with threshold
│
┌────────┴────────┐
│ │
Below Above
│ │
▼ ▼
NORMAL Start timer
│
▼
Persistence check
│
┌──────┴──────┐
│ │
Short Long
│ │
▼ ▼
Ignore ALERT
35. Optional temperature monitoring
Add a temperature sensor:
ESP32
│
├── Voltage
├── Current
├── Power
└── Temperature
Then:
Current high
+
Temperature high
↓
HIGH RISK
Example:
Current = 11.2 A
Temperature = 68 °C
AI:
"High current is occurring together with elevated
temperature. Continued operation should be investigated."
This is considerably more useful than current monitoring alone.
36. Optional energy calculation
If:
Power = 1.2 kW
and the load operates for:
1 hour
then:
Energy=Power×TimeEnergy=1.2×1=1.2kWh
In software:
energy_kWh +=
(power_watts / 1000.0) *
(elapsed_seconds / 3600.0);
Store:
Energy Today
Energy This Week
Energy This Month
37. Complete project flow
START
│
▼
Power ON ESP32
│
▼
Connect Wi-Fi
│
▼
Initialize ADC
│
▼
Read Voltage/Current
│
▼
RMS Filtering
│
▼
Calculate Power
│
▼
Detect Condition
│
┌───────────┼───────────┐
│ │ │
NORMAL WARNING OVERLOAD
│ │ │
│ │ ▼
│ │ Local protection
│ │ │
│ │ ▼
│ │ n8n alert
│ │ │
│ │ ▼
│ │ AI Agent
│ │ │
│ │ ┌─────┴─────┐
│ │ ▼ ▼
│ │ Diagnosis Action
│ │ │ │
│ │ └─────┬─────┘
│ │ ▼
│ │ Telegram
│ │ │
│ │ ┌────┴────┐
│ │ ▼ ▼
│ │ Text Voice
│ │
└───────────┴───────────────┐
▼
Google Sheets
│
▼
ThingSpeak
│
▼
Web Dashboard
│
▼
LOOP
38. Hardware schematic concept
For a safe isolated prototype:
┌─────────────────────┐
│ AC MAINS │
│ │
│ L ──────┬───────────┼─────── Load
│ │ │
│ │ │
│ Fuse │
│ │ │
│ ▼ │
│ Contactor │
│ │
│ N ─────────────────┼─────── Load
└─────────────────────┘
┌─────────────────────────────────────┐
│ ISOLATED VOLTAGE SENSOR │
│ │
│ AC input ◄──── mains sensing │
│ │
│ Safe output ───────────┐ │
└────────────────────────┼────────────┘
│
▼
Voltage ADC
GPIO34
┌─────────────────────────────────────┐
│ CURRENT TRANSFORMER │
│ │
│ AC conductor passes through CT │
│ │
│ CT output │
└───────────────┬─────────────────────┘
│
▼
Burden/filter
│
▼
Current ADC
GPIO35
┌──────────────────┐
│ ESP32 │
│ │
│ GPIO34 ◄ Voltage │
│ GPIO35 ◄ Current │
│ │
│ GPIO25 ─► Green │
│ GPIO26 ─► Red │
│ GPIO27 ─► Buzzer │
│ GPIO14 ─► Relay │
│ │
│ Wi-Fi │
└────────┬─────────┘
│
▼
Internet
│
▼
n8n
Do not use this conceptual diagram as a mains wiring drawing. The mains side should be designed according to the sensor/contactor manufacturer's ratings and applicable electrical standards.
39. Software folder structure
A professional GitHub repository could look like:
AI-Energy-Monitor/
│
├── README.md
│
├── hardware/
│ ├── schematic/
│ │ ├── schematic.pdf
│ │ └── wiring-diagram.png
│ │
│ ├── bom/
│ │ └── bill-of-materials.csv
│ │
│ └── calibration/
│ └── calibration-procedure.md
│
├── esp32/
│ ├── src/
│ │ └── energy_monitor.ino
│ │
│ └── config/
│ └── config.example.h
│
├── n8n/
│ ├── measurement_logger.json
│ ├── safety_alert.json
│ └── telegram_ai_agent.json
│
├── dashboard/
│ ├── index.html
│ ├── style.css
│ └── app.js
│
├── docs/
│ ├── architecture.md
│ ├── installation.md
│ ├── calibration.md
│ ├── testing.md
│ └── troubleshooting.md
│
└── images/
├── architecture.png
├── schematic.png
└── dashboard.png
40. Bill of materials
Item
Qty
ESP32 DevKit
1
Isolated AC voltage sensor
1
CT/current sensor
1
Burden resistor/filter components
1 set
5 V/3.3 V regulated supply
1
Relay/contactor
1
Buzzer
1
Green LED
1
Red LED
1
Resistors
Assorted
OLED display
Optional
Temperature sensor
Optional
PCB/perfboard
1
Fuse/MCB
As required
Enclosure
1
Terminal blocks
As required
41. Calibration procedure
This is one of the most important parts of the project.
Voltage calibration
Use a trusted multimeter.
Suppose:
Reference meter = 230.5 V
ESP32 = 218.2 V
Correction factor:
Kv=218.2230.5
Then:
K_v ≈ 1.056
Apply:
voltage = measuredVoltage * 1.056;
Repeat at several operating points.
Current calibration
Reference:
Clamp meter = 5.20 A
ESP32 = 4.78 A
Ki=4.785.20
Then:
current = measuredCurrent * Ki;
Test:
1 A
3 A
5 A
7 A
9 A
Create a calibration table.
42. Testing plan
Test 1 — No load
Expected:
Voltage ≈ supply voltage
Current ≈ 0 A
Status = NORMAL
Test 2 — Small load
Current = 2 A
Status = NORMAL
Test 3 — Warning
Current = 8.5 A
Status = WARNING
Telegram = optional warning
Test 4 — Overload
Current = 10.5 A
Status = OVERLOAD
Telegram = ON
AI = ON
Voice = ON
Test 5 — Critical
Current > 12 A
Status = CRITICAL
Buzzer = ON
Local protection = ON
Telegram = ON
Voice = ON
Test 6 — Recovery
Current returns to 4 A
Status:
NORMAL
Recovery notification:
ON
43. Fault-handling strategy
Wi-Fi failure
ESP32
│
├── continue measuring
├── continue local protection
└── buffer data
Do not make electrical protection dependent on Wi-Fi.
n8n unavailable
ESP32
│
├── local protection continues
└── retry cloud connection
AI unavailable
ESP32
│
└── threshold alert still works
The system should remain operational without AI.
44. Recommended reliability hierarchy
This is very important for your project presentation:
LEVEL 1
Physical electrical protection
↓
LEVEL 2
ESP32 deterministic protection
↓
LEVEL 3
n8n automation
↓
LEVEL 4
Cloud monitoring
↓
LEVEL 5
AI diagnosis
↓
LEVEL 6
Human notification
Therefore:
AI explains the event; it does not replace electrical protection.
45. Why this is an "Agentic IoT" project
A basic IoT system does:
Sensor → Cloud → Dashboard
Your system can do:
Sensor
↓
Event detection
↓
Context collection
↓
AI reasoning
↓
Tool selection
↓
Historical-data lookup
↓
Diagnosis
↓
Notification
↓
Voice communication
↓
Human decision
That's the key distinction.
The n8n AI Agent can be connected to tools and external services, which fits this architecture well.
46. Example complete scenario
Imagine a heater and several appliances are connected.
Normal:
Voltage = 231 V
Current = 4.2 A
Power = 970 VA
Then another appliance starts:
Voltage = 230 V
Current = 8.7 A
Power = 2001 VA
System:
WARNING
Then current rises:
Voltage = 229 V
Current = 10.8 A
Power = 2473 VA
ESP32:
OVERLOAD
n8n receives:
{
"voltage": 229,
"current": 10.8,
"power": 2473,
"status": "OVERLOAD"
}
AI Agent analyzes the event.
Google Sheets records it.
ThingSpeak graphs it.
Telegram receives:
⚠️ OVERLOAD DETECTED
Current: 10.8 A
Limit: 10 A
Power: 2.47 kVA
The monitored load is exceeding its configured
continuous current limit.
Then TTS generates:
"Warning. Electrical overload detected. Current is 10.8 amperes. Please reduce the connected load."
Telegram receives that as a voice message.
47. Advanced version
For an even stronger project, add:
ESP32
│
├── Voltage
├── Current
├── Power
├── Power factor
├── Frequency
├── Energy
├── Temperature
└── Relay status
│
▼
n8n
│
├── Database
├── ThingSpeak
├── Google Sheets
├── AI Agent
├── Telegram
├── Voice AI
└── Web dashboard
Then add predictive analytics:
Historical current
│
▼
Trend analysis
│
▼
Anomaly detection
│
▼
"Load appears to be increasing"
│
▼
Predictive warning
48. Project objectives
You can use these directly as your project objectives:
Design an ESP32-based real-time electrical monitoring system.
Measure AC voltage and load current using appropriately isolated sensors.
Calculate RMS voltage, RMS current and power.
Detect electrical overload conditions in real time.
Implement local deterministic safety logic.
Send sensor measurements to an n8n automation server.
Store measurements automatically in Google Sheets.
Visualize measurements using ThingSpeak.
Implement an AI Agent for intelligent event analysis.
Generate automated Telegram notifications.
Generate AI-based voice alerts.
Provide a conversational Telegram interface.
Implement historical-data analysis.
Provide a web-based monitoring dashboard.
Design the system to continue local protection even if cloud services fail.
49. Expected output
The final system should provide:
AI ENERGY MONITOR
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
REAL-TIME AUTOMATION AI
│ │ │
▼ ▼ ▼
Voltage/Current n8n Workflow Diagnosis
Power/Energy Google Sheets Prediction
│ ThingSpeak Explanation
│ │ │
└─────────────────┼──────────────────┘
│
▼
NOTIFICATION
│
┌───────┴────────┐
▼ ▼
Telegram Voice Alert
50. Technology stack
Layer
Technology
Microcontroller
ESP32
Firmware
Arduino/C++
Sensor interface
ADC
Network
Wi-Fi
Automation
n8n
AI Agent
n8n AI Agent + LLM
Voice
TTS API
Notification
Telegram Bot
Database/logging
Google Sheets
IoT cloud
ThingSpeak
Dashboard
HTML/CSS/JavaScript
API
REST/HTTPS
Data format
JSON
51. Documentation links
For implementation, these official references are particularly useful:
“AI-Powered Agentic IoT-Based Real-Time Electrical Voltage, Current and Power Monitoring System with Intelligent Overload Detection, Automated Safety Alerts and Telegram Voice Notifications Using ESP32 and n8n”
Short version:
“AI-Powered ESP32 Agentic IoT Energy Monitoring and Intelligent Overload Protection System”
This architecture gives you a complete chain:
ESP32 → Electrical Sensors → RMS/Power → Local Overload Detection → n8n → Google Sheets + ThingSpeak → AI Agent → Telegram Text → AI Voice Alert → Web Dashboard.
The most important engineering decision is to keep fast, deterministic overload protection on the ESP32/hardware side, while using n8n/AI for analysis, context, logging and communication. That makes the project substantially more robust than an architecture where an LLM is placed in the safety-critical control loop.
