Yes . This can be designed as a complete AI-powered bidirectional EV charging + Smart Grid + IoT + ESP32 + n8n + Telegram + Google Sheets + ThingSpeak project.
I would structure the project as a modular system so that the power electronics, ESP32 control, cloud/IoT layer, automation, and AI agent are separated. That makes the prototype much safer to develop and easier to demonstrate.
1. Project title
AI-Powered Bidirectional EV Charging System with Smart Grid, ESP32, IoT Cloud, n8n Automation and AI Agent
Short description
The system is an IoT-enabled bidirectional EV charging prototype in which an ESP32 monitors electrical parameters and controls a bidirectional charger/inverter. The system can operate in:
-
G2V — Grid to Vehicle: charge the EV.
-
V2G — Vehicle to Grid: discharge energy from the EV toward the grid/load.
-
V2H — Vehicle to Home: use EV energy to supply a local load.
-
Smart charging: schedule charging according to grid conditions, electricity price, battery SOC, solar generation, etc.
-
AI-assisted operation: an AI agent analyzes system information and recommends/initiates permitted actions.
-
IoT monitoring: measurements are sent to a cloud dashboard.
-
n8n automation: events trigger workflows.
-
Telegram: alarms and voice notifications are delivered to the operator.
-
Google Sheets: operating data and events can be logged.
-
ThingSpeak: electrical/IoT data can be visualized.
-
Web dashboard: provides live status, controls, graphs and historical information.
2. Important architecture decision
For a student/research prototype, I strongly recommend not connecting an ESP32 directly to mains voltage or directly switching a high-power EV battery.
Instead use three layers:
┌─────────────────────────────┐
│ USER / OPERATOR │
│ Web Dashboard / Telegram │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ AI + AUTOMATION │
│ │
│ n8n + AI Agent + Rules │
└──────────────┬──────────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Google Sheets ThingSpeak Telegram
│ │ │
└─────────────────┼──────────────────┘
│
▼
┌─────────────────────────────┐
│ ESP32 │
│ │
│ Sensors + Control + MQTT │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Isolated Power Interface │
│ │
│ Contactors / Drivers / │
│ Protection / Interlocks │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ BIDIRECTIONAL POWER STAGE │
│ │
│ AC ↔ DC / DC ↔ Battery │
└──────────────┬──────────────┘
│
▼
┌─────────────────┐
│ EV Battery / │
│ Battery Emulator│
└─────────────────┘
For an initial prototype, the power stage can be represented by a low-voltage isolated DC/DC converter or laboratory power converter, while the ESP32/IoT/AI architecture is developed completely.
3. Overall system block diagram
SMART GRID
│
│ AC
▼
┌─────────────────┐
│ Grid Meter / CT │
│ Voltage Sensor │
│ Current Sensor │
└────────┬────────┘
│
▼
┌────────────────────────┐
│ BIDIRECTIONAL CHARGER │
│ │
│ AC/DC + DC/DC stage │
└───────────┬────────────┘
│
DC │
▼
┌────────────────────┐
│ EV Battery / │
│ Battery Emulator │
└────────────────────┘
▲
│
SOC / Voltage /
Current / Temp
│
▼
┌──────────────┐
│ ESP32 │
│ │
│ ADC │
│ GPIO │
│ Wi-Fi │
│ MQTT/HTTP │
└──────┬───────┘
│
Internet/Wi-Fi
│
▼
┌─────────────────────┐
│ n8n SERVER │
│ │
│ Trigger │
│ AI Agent │
│ Rules │
│ Database │
│ Notifications │
└───┬─────┬─────┬─────┘
│ │ │
┌─────────┘ │ └──────────┐
▼ ▼ ▼
Telegram Google Sheets ThingSpeak
Alerts Data Logging Dashboard
│
▼
Voice Notification
▲
│
┌──────┴───────┐
│ Web Dashboard│
│ │
│ SOC │
│ Power │
│ Voltage │
│ Current │
│ Mode │
│ Alarms │
└──────────────┘
4. Operating modes
Mode 1 — G2V
Grid supplies energy to the EV.
GRID
│
▼
AC/DC
│
▼
DC BUS
│
▼
BATTERY
The ESP32 monitors:
-
Grid voltage
-
Grid current
-
Charging power
-
Battery voltage
-
Battery current
-
Battery temperature
-
SOC
-
Charging status
Mode 2 — V2G
The EV supplies energy back toward the grid.
BATTERY
│
▼
DC/DC
│
▼
DC/AC
│
▼
GRID
The controller must ensure that the appropriate electrical protection, synchronization, isolation and certified grid-interconnection hardware are present.
For a prototype, this should initially be simulated or implemented using an approved bidirectional power converter, rather than constructing an uncertified grid-tied inverter.
Mode 3 — V2H
The EV supplies a local load.
┌───────────────┐
│ EV BATTERY │
└───────┬───────┘
│
▼
BIDIRECTIONAL
CONVERTER
│
▼
HOME LOAD
Example:
EV → inverter → AC load
5. AI agent concept
The AI agent should not have unrestricted control of the power electronics.
Instead:
AI AGENT
│
▼
┌──────────────┐
│ Decision │
│ / Reasoning │
└──────┬───────┘
│
▼
SAFETY RULES
│
┌─────────┴──────────┐
│ │
ALLOWED BLOCKED
│ │
▼ ▼
ESP32 command Alarm / log
For example, the AI could receive:
{
"soc": 78,
"battery_voltage": 52.4,
"battery_current": 8.2,
"temperature": 31.5,
"grid_power": 1200,
"solar_power": 3500,
"mode": "charging"
}
The AI might produce a structured recommendation:
{
"recommended_mode": "V2H",
"reason": "Solar generation is low and battery SOC is sufficient",
"requested_power_w": 800
}
But the safety controller decides whether the command is actually permitted.
6. AI decision architecture
Use this hierarchy:
AI AGENT
│
▼
High-level decision
│
▼
POLICY ENGINE
│
┌─────┴─────┐
│ │
SAFE UNSAFE
│ │
▼ ▼
COMMAND REJECT
│ │
▼ ▼
ESP32 ALERT
│
▼
HARDWARE SAFETY
│
┌──────┴──────┐
│ │
ENABLE TRIP
│ │
▼ ▼
POWER CONTACTOR OFF
This is much better than allowing an LLM to directly control GPIO pins.
7. Hardware architecture
A practical prototype can contain:
Controller
-
ESP32 development board
-
Wi-Fi
-
MQTT or HTTP
-
OLED/LCD display, optional
-
status LEDs
-
buzzer
Sensors
Depending on the prototype:
-
Voltage sensor
-
Current sensor
-
Temperature sensor
-
Battery voltage measurement
-
Battery current measurement
-
SOC information from BMS
-
AC power meter
-
Grid frequency measurement
-
Solar generation measurement
Protection
Use appropriate hardware-rated protection such as:
-
Fuse
-
MCB
-
DC fuse
-
Contactor
-
Emergency-stop circuit
-
Overcurrent protection
-
Overvoltage protection
-
Undervoltage protection
-
Thermal protection
-
Isolation
-
Reverse-polarity protection
-
BMS protection
The exact protection components must be selected based on the actual voltage/current/power rating of the prototype.
8. ESP32 wiring concept
A simplified low-voltage prototype could look like:
ESP32
┌─────────────────┐
│ │
Voltage ---->│ ADC │
Sensor │ │
│ │
Current ---->│ ADC │
Sensor │ │
│ │
Temp ------->│ GPIO/ADC │
Sensor │ │
│ │
BMS -------->│ UART │
│ │
│ Wi-Fi │────────── Internet
│ │
│ GPIO │
└───────┬─────────┘
│
┌───────▼────────┐
│ Isolated Driver│
└───────┬────────┘
│
▼
CONTACTOR
│
▼
POWER STAGE
Do not connect mains voltage directly to an ESP32 ADC. Use suitably rated, isolated measurement equipment/modules .
9. Suggested ESP32 pin assignment
Example only:
| Function | ESP32 |
|---|---|
| Battery voltage | GPIO34 / ADC |
| Battery current | GPIO35 / ADC |
| Temperature | GPIO32 |
| Emergency input | GPIO27 |
| Contactor enable | GPIO26 |
| Charger enable | GPIO25 |
| Status LED | GPIO2 |
| BMS UART RX | GPIO16 |
| BMS UART TX | GPIO17 |
| I2C SDA | GPIO21 |
| I2C SCL | GPIO22 |
The actual pinout should be adapted to the particular ESP32 board and peripherals.
10. Software architecture
ESP32
│
├── Sensor acquisition
│
├── Filtering
│
├── Local safety checks
│
├── State machine
│
├── Wi-Fi
│
├── MQTT/HTTP
│
└── Command receiver
│
▼
n8n
│
┌────┼──────────────┐
│ │ │
▼ ▼ ▼
AI Database Alerts
Agent
│
├──────────► Telegram
│
├──────────► Google Sheets
│
└──────────► ThingSpeak
11. ESP32 state machine
A state machine makes the system much more reliable.
┌────────────┐
│ INIT │
└─────┬──────┘
▼
┌────────────┐
│ SELF CHECK │
└─────┬──────┘
│
PASS │
▼
┌────────────┐
│ IDLE │
└─────┬──────┘
│
┌──────────┼───────────┐
▼ ▼ ▼
CHARGE V2H V2G*
│ │ │
└──────────┼───────────┘
▼
┌────────────┐
│ MONITORING │
└─────┬──────┘
│
Fault detected
▼
┌────────────┐
│ FAULT │
└─────┬──────┘
│
▼
SAFE SHUTDOWN
* V2G should only be enabled with an appropriate certified/isolated grid interface.
12. ESP32 example firmware
Below is a prototype-level firmware skeleton. It demonstrates the IoT/control architecture rather than providing a mains-connected charger controller.
#include <WiFi.h>
#include <HTTPClient.h>
const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASS = "YOUR_PASSWORD";
const int VOLTAGE_PIN = 34;
const int CURRENT_PIN = 35;
const int TEMP_PIN = 32;
const int CHARGER_ENABLE = 25;
const int CONTACTOR = 26;
const int STATUS_LED = 2;
const int ESTOP_PIN = 27;
float batteryVoltage = 0.0;
float batteryCurrent = 0.0;
float temperature = 0.0;
float power = 0.0;
String operatingMode = "IDLE";
unsigned long lastUpload = 0;
void setup() {
Serial.begin(115200);
pinMode(CHARGER_ENABLE, OUTPUT);
pinMode(CONTACTOR, OUTPUT);
pinMode(STATUS_LED, OUTPUT);
pinMode(ESTOP_PIN, INPUT_PULLUP);
digitalWrite(CHARGER_ENABLE, LOW);
digitalWrite(CONTACTOR, LOW);
WiFi.begin(WIFI_SSID, WIFI_PASS);
Serial.print("Connecting WiFi");
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println();
Serial.println("WiFi connected");
}
void readSensors() {
int voltageRaw = analogRead(VOLTAGE_PIN);
int currentRaw = analogRead(CURRENT_PIN);
int tempRaw = analogRead(TEMP_PIN);
/*
Replace these equations with calibration
equations for your actual isolated sensors.
*/
batteryVoltage = voltageRaw * 0.01;
batteryCurrent = currentRaw * 0.01;
temperature = tempRaw * 0.1;
power = batteryVoltage * batteryCurrent;
}
bool safetyCheck() {
if (digitalRead(ESTOP_PIN) == LOW) {
return false;
}
if (temperature > 50.0) {
return false;
}
if (batteryVoltage > 60.0) {
return false;
}
return true;
}
void emergencyShutdown() {
digitalWrite(CHARGER_ENABLE, LOW);
digitalWrite(CONTACTOR, LOW);
operatingMode = "FAULT";
Serial.println("EMERGENCY SHUTDOWN");
}
void setCharging(bool enable) {
if (!safetyCheck()) {
emergencyShutdown();
return;
}
if (enable) {
digitalWrite(CONTACTOR, HIGH);
delay(100);
digitalWrite(CHARGER_ENABLE, HIGH);
operatingMode = "G2V";
} else {
digitalWrite(CHARGER_ENABLE, LOW);
digitalWrite(CONTACTOR, LOW);
operatingMode = "IDLE";
}
}
void uploadData() {
if (WiFi.status() != WL_CONNECTED)
return;
HTTPClient http;
String url =
"https://your-server.example/api/telemetry";
http.begin(url);
http.addHeader(
"Content-Type",
"application/json"
);
String payload = "{";
payload += "\"voltage\":" +
String(batteryVoltage, 2) + ",";
payload += "\"current\":" +
String(batteryCurrent, 2) + ",";
payload += "\"power\":" +
String(power, 2) + ",";
payload += "\"temperature\":" +
String(temperature, 2) + ",";
payload += "\"mode\":\"" +
operatingMode + "\"";
payload += "}";
int response =
http.POST(payload);
Serial.print("HTTP response: ");
Serial.println(response);
http.end();
}
void loop() {
readSensors();
if (!safetyCheck()) {
emergencyShutdown();
}
if (millis() - lastUpload > 10000) {
lastUpload = millis();
uploadData();
}
delay(1000);
}
For a real system, sensor calibration, filtering, watchdog handling, communication authentication, command validation, fault handling and hardware interlocks need to be considerably more robust.
13. Recommended MQTT message structure
Instead of sending arbitrary strings, use structured JSON.
ESP32 → n8n
{
"device_id": "EVSE_001",
"timestamp": "2026-09-25T08:00:00",
"mode": "G2V",
"battery_voltage": 52.4,
"battery_current": 8.2,
"power": 429.68,
"soc": 78,
"temperature": 31.5,
"grid_voltage": 230.2,
"grid_current": 2.1,
"grid_power": 483.4,
"fault": false
}
n8n → ESP32
{
"command": "SET_MODE",
"mode": "G2V",
"power_limit": 500,
"request_id": "REQ_001"
}
14. n8n workflow
The central automation could be:
ESP32
│
▼
┌──────────────┐
│ MQTT / HTTP │
│ Trigger │
└──────┬───────┘
▼
┌──────────────┐
│ Parse JSON │
└──────┬───────┘
▼
┌──────────────┐
│ Validate │
│ Data │
└──────┬───────┘
▼
┌──────────────┐
│ Safety Rules │
└──────┬───────┘
│
┌───────┼─────────┐
▼ ▼ ▼
Normal Warning Critical
│ │ │
▼ ▼ ▼
Sheets Telegram Telegram
│ │ │
▼ ▼ ▼
ThingSpeak Voice Voice
│
▼
AI Agent
│
▼
Recommendation
│
▼
Policy Check
│
▼
ESP32
15. n8n AI-agent workflow
A second workflow can handle intelligent decisions:
Scheduler
│
▼
Read system status
│
▼
Read energy information
│
▼
AI Agent
│
┌──────────┼──────────┐
▼ ▼ ▼
Charging V2H Idle
│ │ │
└──────────┼──────────┘
▼
Safety Validator
│
┌───────┴────────┐
│ │
VALID INVALID
│ │
▼ ▼
ESP32 command Telegram
│
▼
Confirmation
│
▼
Google Sheets
16. AI prompt architecture
Instead of asking an AI:
"Control the charger."
give it structured information and strict constraints.
Example system instruction:
You are an energy-management assistant.
Your role is to analyze EV charging system telemetry
and recommend an operating mode.
Allowed modes:
- IDLE
- G2V
- V2H
Never directly bypass safety limits.
Never request operation if:
- Emergency stop is active
- Battery temperature exceeds configured limit
- Battery voltage exceeds configured limit
- BMS reports a fault
- Communication status is invalid
Return JSON only:
{
"mode": "...",
"power_limit_w": 0,
"reason": "...",
"alert": false
}
For actual deployment, the permitted operating ranges should come from the battery/BMS and power-converter design rather than being invented by the AI.
17. Telegram notification system
Example event:
ESP32
│
│ High temperature
▼
n8n
│
├── Log event
│
├── AI analysis
│
└── Telegram
│
▼
Operator
Telegram text:
⚠️ EV ENERGY SYSTEM ALERT
Device: EVSE_001
Battery temperature: 51.2 °C
SOC: 74 %
Mode: G2V
Action:
Charging disabled.
Reason:
Temperature safety threshold exceeded.
For voice:
Sensor event
│
▼
n8n
│
▼
Text-to-Speech
│
▼
Audio file
│
▼
Telegram
│
▼
Operator hears alert
18. Google Sheets logging
A spreadsheet can contain:
| Timestamp | Device | Mode | Voltage | Current | Power | SOC | Temperature | Fault |
|---|---|---|---|---|---|---|---|---|
| 08:00 | EVSE001 | G2V | 52.4 | 8.2 | 429 | 78 | 31.5 | No |
| 08:01 | EVSE001 | G2V | 52.5 | 8.1 | 425 | 79 | 31.7 | No |
| 08:02 | EVSE001 | IDLE | 52.6 | 0 | 0 | 79 | 31.9 | No |
This provides an easy source for:
-
daily energy
-
charging sessions
-
faults
-
temperature history
-
SOC history
-
power consumption
-
operating hours
19. ThingSpeak architecture
ESP32
│
│ HTTP/MQTT
▼
ThingSpeak
│
├── Field 1 → Voltage
├── Field 2 → Current
├── Field 3 → Power
├── Field 4 → SOC
├── Field 5 → Temperature
├── Field 6 → Grid Power
├── Field 7 → Mode
└── Field 8 → Fault
Dashboard:
┌─────────────────────────────────────────┐
│ EV SMART ENERGY DASHBOARD │
├─────────────────────────────────────────┤
│ │
│ SOC 78 % │
│ Battery 52.4 V │
│ Current 8.2 A │
│ Power 429 W │
│ Temperature 31.5 °C │
│ │
│ Mode: G2V │
│ Status: NORMAL │
│ │
│ Power Graph ──────────────── │
│ SOC Graph ──────────────── │
│ Temp Graph ──────────────── │
└─────────────────────────────────────────┘
20. Web dashboard
A separate web application can provide a more attractive interface.
Frontend
Possible stack:
HTML
CSS
JavaScript
Chart.js
or:
React
+
Chart.js
Dashboard
EV ENERGY MANAGER
┌────────────┐ ┌────────────┐ ┌────────────┐
│ SOC │ │ POWER │ │ BATTERY │
│ │ │ │ │ TEMP │
│ 78 % │ │ 429 W │ │ 31.5 °C │
└────────────┘ └────────────┘ └────────────┘
┌───────────────────────────────────────────┐
│ OPERATING MODE │
│ │
│ ● G2V ○ V2H ○ IDLE │
└───────────────────────────────────────────┘
┌───────────────────────────────────────────┐
│ POWER HISTORY │
│ │
│ /\ │
│ / \ /\ │
│ ____/ \______/ \______ │
│ │
└───────────────────────────────────────────┘
┌───────────────────────────────────────────┐
│ AI ENERGY ASSISTANT │
│ │
│ "Battery SOC is sufficient for local │
│ load support. V2H is permitted by │
│ current policy." │
└───────────────────────────────────────────┘
21. Example dashboard HTML
A simple prototype frontend:
<!DOCTYPE html>
<html>
<head>
<title>AI EV Energy Manager</title>
<style>
body {
font-family: Arial;
background: #101820;
color: white;
margin: 0;
}
header {
background: #16232e;
padding: 20px;
text-align: center;
}
.dashboard {
display: grid;
grid-template-columns:
repeat(auto-fit, minmax(200px, 1fr));
gap: 20px;
padding: 25px;
}
.card {
background: #1c2d39;
padding: 25px;
border-radius: 15px;
text-align: center;
}
.value {
font-size: 35px;
color: #00e676;
font-weight: bold;
}
button {
padding: 15px 25px;
margin: 10px;
border: none;
border-radius: 10px;
cursor: pointer;
}
.charge {
background: #00c853;
}
.stop {
background: #ff1744;
color: white;
}
</style>
</head>
<body>
<header>
<h1>AI EV Smart Energy Manager</h1>
</header>
<div class="dashboard">
<div class="card">
<h3>Battery SOC</h3>
<div class="value" id="soc">78%</div>
</div>
<div class="card">
<h3>Voltage</h3>
<div class="value" id="voltage">52.4 V</div>
</div>
<div class="card">
<h3>Current</h3>
<div class="value" id="current">8.2 A</div>
</div>
<div class="card">
<h3>Power</h3>
<div class="value" id="power">429 W</div>
</div>
<div class="card">
<h3>Temperature</h3>
<div class="value" id="temperature">31.5 °C</div>
</div>
</div>
<div style="text-align:center">
<button class="charge"
onclick="setMode('G2V')">
CHARGE
</button>
<button onclick="setMode('V2H')">
V2H
</button>
<button class="stop"
onclick="setMode('IDLE')">
STOP
</button>
</div>
<script>
async function setMode(mode) {
await fetch("/api/mode", {
method: "POST",
headers: {
"Content-Type":
"application/json"
},
body: JSON.stringify({
mode: mode
})
});
}
async function updateDashboard() {
const response =
await fetch("/api/status");
const data =
await response.json();
document.getElementById("soc")
.innerText = data.soc + "%";
document.getElementById("voltage")
.innerText =
data.voltage + " V";
document.getElementById("current")
.innerText =
data.current + " A";
document.getElementById("power")
.innerText =
data.power + " W";
document.getElementById("temperature")
.innerText =
data.temperature + " °C";
}
setInterval(updateDashboard, 3000);
updateDashboard();
</script>
</body>
</html>
22. Complete data flow
The complete project can operate as follows:
┌──────────────┐
│ EV BATTERY │
└──────┬───────┘
│
Electrical data
│
▼
┌────────────────┐
│ ESP32 │
│ │
│ V/I/T/SOC │
└───────┬────────┘
│
Wi-Fi/MQTT
│
▼
┌────────────────┐
│ n8n │
└───────┬────────┘
│
┌───────────┼────────────┐
│ │ │
▼ ▼ ▼
Google ThingSpeak Database
Sheets
│
│
▼
Analytics
│
▼
AI Agent
│
▼
Decision Engine
│
┌───┴────┐
│ │
▼ ▼
SAFE UNSAFE
│ │
▼ ▼
ESP32 Telegram
│ Alert
▼
Power Stage
23. Example AI conversation
Operator
What is the current EV status?
AI Agent
EVSE-001 status:
SOC: 78%
Battery voltage: 52.4 V
Battery current: 8.2 A
Power: 430 W
Temperature: 31.5 °C
Mode: G2V
Fault: None
The system is operating normally.
Operator
Why is charging slow?
AI
Current charging power is approximately 430 W.
Possible causes include:
- configured power limit
- available grid power
- charger operating state
- battery charging constraints
The current telemetry does not by itself identify
which condition is limiting power.
24. Example Telegram conversation
USER:
Status
BOT:
🔋 EV STATUS
SOC: 78%
Voltage: 52.4 V
Current: 8.2 A
Power: 429 W
Temperature: 31.5 °C
Mode: G2V
Fault: None
Then:
USER:
Stop charging
n8n:
Telegram
│
▼
Parse command
│
▼
Safety validation
│
▼
ESP32 command
│
▼
ESP32
│
▼
Contactor/charger disabled
│
▼
Confirmation
Telegram:
🛑 Charging stopped.
Device: EVSE-001
Mode: IDLE
Power: 0 W
25. Fault-management workflow
This is one of the most important parts.
Sensor
│
▼
ESP32
│
▼
Is value normal?
│
┌┴──────────────┐
│ │
YES NO
│ │
▼ ▼
Continue Local shutdown
│ │
▼ ▼
Cloud Fault state
│ │
▼
n8n alert
│
┌────────┼────────┐
▼ ▼ ▼
Telegram Sheets Dashboard
Example faults:
OVERVOLTAGE
OVERCURRENT
OVERTEMPERATURE
UNDERVOLTAGE
BMS_FAULT
COMMUNICATION_LOSS
EMERGENCY_STOP
GRID_FAULT
CONTACTOR_FAULT
SENSOR_FAULT
26. Communication-loss protection
Suppose Wi-Fi disappears.
The system should not wait for an AI decision.
Instead:
Wi-Fi lost
│
▼
ESP32 detects timeout
│
▼
Local safety policy
│
├── Continue in predefined safe state
│
└── OR shutdown
This is a key principle:
Cloud/AI failure must never become a hardware safety failure.
27. Suggested n8n workflows
I would divide the project into six workflows.
Workflow 1 — Telemetry
ESP32
↓
MQTT/HTTP
↓
Validate
↓
Database
↓
ThingSpeak
↓
Google Sheets
Workflow 2 — Fault alert
Telemetry
↓
IF fault = true
↓
Create alert
↓
Telegram
↓
Voice generation
↓
Telegram voice message
Workflow 3 — AI energy management
Schedule
↓
Get telemetry
↓
Get energy conditions
↓
AI Agent
↓
Safety policy
↓
ESP32
Workflow 4 — Telegram commands
Telegram
↓
Receive command
↓
Parse
↓
Validate
↓
ESP32
↓
Confirmation
Workflow 5 — Daily report
Cron
↓
Google Sheets
↓
Calculate:
Energy
Sessions
Faults
Peak power
↓
AI summary
↓
Telegram
Workflow 6 — Emergency notification
ESP32
↓
Critical fault
↓
n8n
↓
Immediate Telegram
↓
Voice alert
↓
Dashboard RED
28. Daily AI report example
The system could automatically send:
📊 DAILY EV ENERGY REPORT
Device: EVSE-001
Charging sessions: 4
Total charging energy: 3.8 kWh
V2H energy: 1.2 kWh
Peak power: 1.5 kW
Average battery temperature: 32.1 °C
Faults:
1 minor warning
0 critical faults
AI observation:
The system remained within the configured
operating limits during the reporting period.
29. Database structure
A simple database table could be:
CREATE TABLE telemetry (
id INTEGER PRIMARY KEY,
device_id VARCHAR(50),
timestamp TIMESTAMP,
mode VARCHAR(20),
voltage FLOAT,
current FLOAT,
power FLOAT,
soc FLOAT,
temperature FLOAT,
grid_voltage FLOAT,
grid_power FLOAT,
fault BOOLEAN
);
Fault table:
CREATE TABLE faults (
id INTEGER PRIMARY KEY,
device_id VARCHAR(50),
timestamp TIMESTAMP,
fault_code VARCHAR(50),
severity VARCHAR(20),
description TEXT,
resolved BOOLEAN
);
30. Energy calculation
For sampled power data:
E=∫P(t) dtE = \int P(t)\,dt
For digital sampling:
E≈∑PiΔtE \approx \sum P_i \Delta t
For example, if:
Power = 500 W
Time = 2 hours
then:
E=500×2=1000WhE = 500 \times 2 = 1000Wh
or:
E=1kWhE = 1kWh
The software can accumulate this continuously.
31. Smart charging algorithm
A simple first-generation algorithm:
START
│
▼
Read SOC
│
▼
Read grid power
│
▼
Read solar power
│
▼
Read battery temperature
│
▼
Check safety
│
▼
SOC < target?
│
┌┴───────────┐
YES NO
│ │
▼ ▼
Can charge? IDLE
│
▼
Calculate power limit
│
▼
Charge
A more advanced version:
Solar surplus
+
Grid condition
+
Battery SOC
+
Energy price
+
User schedule
+
Battery constraints
│
▼
AI Agent
│
▼
Optimization
│
▼
Safety policy
│
▼
Power command
32. Project development stages
Do not build everything simultaneously.
Stage 1 — ESP32
Build:
ESP32
↓
Temperature
↓
Voltage
↓
Current
↓
Serial monitor
Verify measurements.
Stage 2 — IoT
Add:
ESP32
↓
Wi-Fi
↓
HTTP/MQTT
↓
Cloud
Stage 3 — Dashboard
Add:
ESP32
↓
Server
↓
Web dashboard
Stage 4 — n8n
Add:
ESP32 → n8n → Google Sheets
Stage 5 — Telegram
Add:
ESP32
↓
n8n
↓
Telegram
Stage 6 — Voice
Add:
n8n
↓
TTS
↓
Telegram voice
Stage 7 — AI
Add:
Telemetry
↓
AI Agent
↓
Recommendation
Stage 8 — Control
Only after the above is stable:
AI
↓
Policy
↓
ESP32
↓
Low-voltage test load
Stage 9 — Bidirectional power
Finally integrate an appropriate power converter and battery/BMS system under suitable electrical protection and supervision.
33. Complete final architecture
┌─────────────────┐
│ USER │
└────────┬────────┘
│
┌────────────────┼───────────────┐
│ │ │
▼ ▼ ▼
Web App Telegram Voice
│ │ │
└────────────────┼───────────────┘
│
▼
┌─────────────────┐
│ n8n │
│ │
│ Automation │
│ AI Agent │
│ Rules │
│ Notifications │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Google Sheets ThingSpeak Database
│ │ │
└─────────────────┼──────────────────┘
│
▼
┌─────────────────┐
│ ESP32 │
│ │
│ Sensors │
│ BMS │
│ Wi-Fi │
│ MQTT │
│ State Machine │
│ Safety Logic │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Isolation / │
│ Protection │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Bidirectional │
│ Power Converter │
└────────┬────────┘
│
┌─────────────────┴─────────────────┐
│ │
▼ ▼
EV Battery Smart Grid
│ │
└───────────────┬───────────────────┘
│
▼
Home / Load
34. Recommended project deliverables
For a final-year project / research project, your documentation can be divided into:
-
Abstract
-
Introduction
-
Problem statement
-
Existing system
-
Proposed system
-
Objectives
-
System architecture
-
Hardware requirements
-
Software requirements
-
ESP32 design
-
Sensor interface
-
BMS interface
-
Bidirectional charging concept
-
G2V operation
-
V2G operation
-
V2H operation
-
Smart-grid integration
-
IoT architecture
-
MQTT/HTTP communication
-
n8n workflow
-
AI-agent architecture
-
Telegram integration
-
Voice-alert system
-
Google Sheets integration
-
ThingSpeak integration
-
Web dashboard
-
Database
-
Safety architecture
-
Fault handling
-
Software flowcharts
-
Hardware schematic
-
ESP32 source code
-
Web application source code
-
n8n workflow
-
Testing
-
Results
-
Performance analysis
-
Limitations
-
Future scope
-
Conclusion
35. What the finished demonstration can look like
A particularly effective demonstration is:
SOLAR / GRID
│
▼
EV CHARGER
│
▼
ESP32
│
┌────────┴────────┐
│ │
Sensors BMS
│ │
└────────┬────────┘
▼
n8n
│
┌───────────┼─────────────┐
│ │ │
▼ ▼ ▼
AI Telegram Sheets
│ │
│ ▼
│ Voice alert
│
▼
Safety policy
│
▼
ESP32
│
▼
Power stage
Then demonstrate three scenarios:
Scenario A — Normal charging
SOC 40%
↓
AI/n8n detects charging requirement
↓
Safety checks
↓
G2V
↓
ESP32
↓
Charger
Scenario B — High temperature
Temperature rises
↓
ESP32 detects threshold
↓
Local protection
↓
Charging disabled
↓
n8n
↓
Telegram text + voice alert
↓
Google Sheets event
Scenario C — Smart V2H
EV SOC sufficiently high
+
Home load request
+
Safety conditions valid
↓
AI Agent recommendation
↓
Policy validation
↓
ESP32
↓
Approved bidirectional converter
↓
Home load
This architecture gives you a strong AI + IoT + embedded + automation + cloud + energy-management project while keeping the safety-critical power-control portion separate from the AI layer. For an actual grid-connected EV system, the power converter, isolation, BMS, protection, anti-islanding/grid synchronization and applicable electrical standards must be handled with appropriately rated hardware and qualified supervision; the ESP32 should not be treated as the sole safety controller.
