Yes. I can structure this as a complete engineering-project document covering the smart pillow hardware, ESP32 firmware, AI/agent layer, n8n workflow, Telegram voice alerts, Google Sheets logging, ThingSpeak dashboard, webpage, circuit schematic, data flow, and testing.
I’ll treat the system as a sleep-monitoring prototype, not a medical diagnostic device: it can detect and flag patterns such as unusual movement, breathing-related anomalies, snoring/noise, and sleep-session irregularities, but those signals should not be presented as a clinical diagnosis.
Proposed project title
AI Smart Pillow for Sleep Monitoring & Disorder-Risk Detection using ESP32, IoT, n8n Automation, AI Agent, Telegram Voice Alerts, Google Sheets & ThingSpeak
Core architecture
┌──────────────────────────────┐
│ SMART PILLOW │
│ │
│ ESP32 │
│ ├─ Pressure sensors │
│ ├─ MPU6050 / accelerometer │
│ ├─ MAX30102* │
│ ├─ Microphone* │
│ ├─ Temperature/Humidity │
│ └─ Optional sensors │
└──────────────┬───────────────┘
│ Wi-Fi / MQTT / HTTP
▼
┌──────────────────────────────┐
│ IoT / n8n SERVER │
│ │
│ Webhook → Data processing │
│ ↓ │
│ AI Agent │
│ ↓ │
│ Decision / Classification │
│ ↓ │
│ ┌───────┼────────┐ │
└───┼───────┼────────┼─────────┘
│ │ │
▼ ▼ ▼
Telegram Google ThingSpeak
Voice Sheets Dashboard
Alert
│
▼
User / Caregiver
*The exact sensors should be selected according to the desired measurements and electrical/mechanical constraints. In particular, a pillow-based prototype should not be described as measuring clinical SpO₂ or diagnosing sleep apnea unless it has been appropriately validated.
Main operating cycle
START
│
▼
ESP32 initializes sensors
│
▼
Connect to Wi-Fi
│
▼
Collect sleep data
│
├── Movement
├── Pressure
├── Temperature
├── Sound/snoring features
└── Optional physiological signals
│
▼
Filter / preprocess data
│
▼
Create JSON telemetry
│
▼
Send to n8n Webhook
│
▼
n8n validates data
│
▼
AI Agent analyzes sleep event
│
├────────────── Normal ──────────────┐
│ │
├──────────── Warning ───────────────┤
│ │
└──────────── Critical ──────────────┤
▼
Store / notify
│
┌──────────────────┼─────────────────┐
▼ ▼ ▼
Google Sheets ThingSpeak Telegram
│ │ │
▼ ▼ ▼
History Graphs Voice alert
Example AI-agent decision
The ESP32 could send:
{
"device_id": "SMARTPILLOW_01",
"timestamp": "2026-09-29T21:30:00+05:30",
"movement": 0.72,
"pressure_left": 61,
"pressure_center": 43,
"pressure_right": 18,
"temperature": 28.4,
"humidity": 61,
"sound_level": 68,
"snoring_event": true,
"sleep_state": "sleeping"
}
The n8n/AI layer can transform this into something such as:
{
"sleep_event": "possible_disturbance",
"severity": "warning",
"reason": "Repeated movement and elevated sound events detected",
"action": "log_and_notify"
}
The important design principle is that the AI agent should reason over sensor observations rather than pretending that one sensor reading proves a medical condition.
Telegram alert example
🚨 Smart Pillow Alert
Sleep disturbance detected.
Time: 02:17 AM
Movement: High
Sound event: Detected
Duration: 42 seconds
Sleep state: Interrupted
The system recommends reviewing the sleep-session
data rather than treating this alert as a diagnosis.
For a voice notification:
"Smart Pillow alert. A repeated sleep disturbance
was detected at 2:17 AM. Please review the recorded
sleep data."
n8n workflow
ESP32
│
│ HTTP POST
▼
┌─────────────────┐
│ n8n Webhook │
└────────┬────────┘
▼
┌─────────────────┐
│ Validate JSON │
└────────┬────────┘
▼
┌─────────────────┐
│ Data Processing │
└────────┬────────┘
▼
┌─────────────────┐
│ AI Agent / LLM │
└────────┬────────┘
▼
┌───────┴────────┐
│ │
▼ ▼
Normal event Abnormal/
│ warning
│ │
▼ ▼
Google Sheets Telegram
│ │
▼ ▼
ThingSpeak Text/Voice
│
▼
Dashboard
Suggested n8n nodes
-
Webhook
-
Set / Edit Fields
-
Code – validate and normalize ESP32 data
-
IF – basic threshold checks
-
AI Agent
-
Google Sheets
-
HTTP Request → ThingSpeak
-
Telegram
-
Text-to-Speech service if voice generation is required
-
Telegram audio/message node
-
Error handling / notification workflow
ESP32 hardware block diagram
+-----------------------+
| ESP32 |
| |
| GPIO / I2C / ADC |
+----+----+----+--------+
│ │ │
┌───────────┘ │ └────────────┐
▼ ▼ ▼
Pressure Array MPU6050 Temp/Humidity
│ │ │
└────────────────┼─────────────────┘
│
▼
Sensor Processing
│
▼
Wi-Fi
│
▼
n8n Webhook
Example electrical concept
For an ESP32 Dev Kit:
ESP32 DEVKIT
┌─────────────────────┐
│ │
3V3 ────┼──── Sensor VCC │
GND ────┼──── Sensor GND │
│ │
GPIO21 ─┼──── I2C SDA │
GPIO22 ─┼──── I2C SCL │
│ │
ADC pins ┼──── Pressure │
│ sensors │
GPIO ┼──── Digital │
│ sensors │
└─────────────────────┘
Important: the actual schematic must account for the specific sensor modules, their operating voltage, pull-up resistors, ADC characteristics, current consumption, and whether their outputs are analog, I ²C, SPI, UART, or digital.
ESP32 firmware structure
I would organize the firmware like this:
ESP32
│
├── Wi-Fi Manager
│
├── Sensor Manager
│ ├── Pressure
│ ├── Motion
│ ├── Temperature
│ ├── Humidity
│ └── Audio/event features
│
├── Signal Processing
│
├── Sleep Event Detection
│
├── JSON Generator
│
├── HTTP/MQTT Client
│
├── OTA Update
│
└── Error / watchdog handling
Basic ESP32 Arduino example
#include <WiFi.h>
#include <HTTPClient.h>
#include <ArduinoJson.h>
const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASSWORD = "YOUR_PASSWORD";
const char* N8N_WEBHOOK =
"https://YOUR-N8N-SERVER/webhook/smart-pillow";
const int PRESSURE_PIN = 34;
void connectWiFi() {
WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("\nWiFi connected");
}
void sendSleepData() {
int pressure = analogRead(PRESSURE_PIN);
float temperature = 28.4;
float humidity = 61.0;
float movement = 0.72;
float soundLevel = 68.0;
bool snoringEvent = soundLevel > 65;
StaticJsonDocument<512> doc;
doc["device_id"] = "SMARTPILLOW_01";
doc["pressure"] = pressure;
doc["temperature"] = temperature;
doc["humidity"] = humidity;
doc["movement"] = movement;
doc["sound_level"] = soundLevel;
doc["snoring_event"] = snoringEvent;
String payload;
serializeJson(doc, payload);
HTTPClient http;
http.begin(N8N_WEBHOOK);
http.addHeader("Content-Type", "application/json");
int responseCode = http.POST(payload);
Serial.print("HTTP response: ");
Serial.println(responseCode);
Serial.println(http.getString());
http.end();
}
void setup() {
Serial.begin(115200);
pinMode(PRESSURE_PIN, INPUT);
connectWiFi();
}
void loop() {
sendSleepData();
delay(10000);
}
For a real deployment, I would add Wi-Fi reconnection, TLS certificate validation, authentication, sensor calibration, non-blocking timing, watchdog recovery, OTA firmware updates, local buffering when Wi-Fi is unavailable, and rate limiting.
AI-agent logic
The AI agent should receive structured observations rather than raw uncontrolled text.
Example system instruction:
You are the analysis component of a smart sleep-monitoring IoT system.
Analyze the supplied sensor observations.
Do not diagnose medical conditions.
Classify the observation as:
NORMAL
DISTURBANCE
WARNING
Consider:
- movement
- pressure changes
- sound events
- duration
- repeated events
- temperature
- sleep-state transitions
Return valid JSON only:
{
"classification": "...",
"severity": "...",
"reason": "...",
"notify": true/false
}
This creates a much safer separation:
Sensors
↓
Measurements
↓
Signal processing
↓
Rules / thresholds
↓
AI interpretation
↓
Notification
rather than:
Sensor → AI → "You have sleep apnea"
The latter would be an unjustified medical conclusion.
Google Sheets database
A useful sheet structure is:
| Timestamp | Device | Movement | Pressure | Temp | Humidity | Sound | Event | Severity |
|---|---|---|---|---|---|---|---|---|
| 21:30 | PILLOW01 | 0.72 | 61 | 28.4 | 61 | 68 | Disturbance | Warning |
| 21:40 | PILLOW01 | 0.18 | 57 | 28.2 | 60 | 35 | Normal | Normal |
This provides a simple historical dataset for later analysis.
ThingSpeak
A possible field mapping:
Field 1 = Movement
Field 2 = Pressure
Field 3 = Temperature
Field 4 = Humidity
Field 5 = Sound level
Field 6 = Sleep state
Field 7 = Disturbance count
Field 8 = Alert severity
Dashboard:
┌───────────────────────────────────────────┐
│ SMART PILLOW DASHBOARD │
├───────────────────────────────────────────┤
│ │
│ Temperature 28.4 °C │
│ Humidity 61 % │
│ Movement 0.72 │
│ Sound 68 dB* │
│ │
│ ───── Movement over time ────────────── │
│ /\ /\ │
│ ____/ \_____/ \_____ │
│ │
│ ───── Disturbance events ───────────── │
│ █ ███ █ │
│ │
└───────────────────────────────────────────┘
*If the microphone is not calibrated, it is better to call this a relative sound level rather than claim an accurate dB measurement.
Webpage
The project can have a local/cloud webpage:
SMART PILLOW AI
┌───────────────────────────────┐
│ 🟢 Device Online │
│ │
│ Current Sleep State │
│ SLEEPING │
│ │
│ Movement █████░ 72% │
│ Pressure ████░░ │
│ Temperature 28.4 °C │
│ Humidity 61% │
│ Sound █████░ │
│ │
│ Events Today: 7 │
│ Warnings: 2 │
└───────────────────────────────┘
Possible architecture:
Browser
│
▼
HTML / CSS / JavaScript
│
▼
Backend/API
│
├──── ThingSpeak
├──── n8n
└──── Database
Complete project data flow
┌─────────────┐
│ PERSON │
└──────┬──────┘
│
▼
┌─────────────┐
│ SMART PILLOW│
└──────┬──────┘
│
Sensor measurements
│
▼
┌─────────────┐
│ ESP32 │
└──────┬──────┘
│
Wi-Fi
│
▼
┌─────────────┐
│ n8n Webhook │
└──────┬──────┘
│
▼
┌─────────────────┐
│ Data Processing │
└────────┬────────┘
│
▼
┌───────────┐
│ AI Agent │
└─────┬─────┘
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
Sheets ThingSpeak Telegram
│ │ │
▼ ▼ ▼
History Dashboard Alert
Telegram conversation concept
SMART PILLOW BOT
│
▼
┌──────────────────────────────┐
│ User: /status │
└──────────────┬───────────────┘
▼
n8n Telegram Trigger
│
▼
Query data
│
▼
AI Agent
│
▼
┌──────────────────────────────┐
│ Bot: │
│ │
│ Current state: Sleeping │
│ Movement: Low │
│ Events tonight: 4 │
│ Last disturbance: 02:17 │
└──────────────────────────────┘
You can also implement commands such as:
/start
/status
/today
/events
/report
/device
/help
Suggested project folders
AI-Smart-Pillow/
│
├── ESP32/
│ ├── smart_pillow.ino
│ ├── sensors.h
│ ├── sensors.cpp
│ ├── wifi_manager.h
│ └── config.h
│
├── n8n/
│ ├── workflow.json
│ ├── ai-agent-prompt.txt
│ └── webhook-schema.json
│
├── Web/
│ ├── index.html
│ ├── style.css
│ └── app.js
│
├── Documentation/
│ ├── architecture.md
│ ├── wiring.md
│ ├── installation.md
│ ├── testing.md
│ └── user-manual.md
│
├── Hardware/
│ ├── block-diagram
│ ├── schematic
│ └── BOM
│
└── README.md
What the full documentation should contain
I would document the finished project in this order:
-
Abstract
-
Introduction
-
Problem statement
-
Objectives
-
Existing-system limitations
-
Proposed system
-
System architecture
-
Hardware requirements
-
Detailed sensor selection
-
ESP32 pin configuration
-
Circuit/schematic
-
Smart-pillow mechanical arrangement
-
Firmware architecture
-
Complete ESP32 source code
-
Wi-Fi communication
-
HTTP/MQTT protocol
-
JSON data format
-
n8n installation
-
Complete n8n workflow
-
AI-agent prompt and logic
-
Telegram bot configuration
-
Telegram voice-alert pipeline
-
Google Sheets integration
-
ThingSpeak integration
-
Web dashboard
-
Database/data model
-
Flowcharts
-
Sequence diagrams
-
Testing methodology
-
Test cases
-
Error handling
-
Security
-
Privacy
-
Limitations
-
Future improvements
-
Cost/BOM
-
Installation procedure
-
Troubleshooting
-
Results
-
Conclusion
One important design decision
For a serious project, I recommend calling the output “sleep monitoring / sleep-event detection” rather than claiming the pillow can independently detect or diagnose a specific sleep disorder. You can still make the project highly sophisticated by using AI to identify patterns and anomalies and then generate alerts for review.
If you want, I can next produce the complete implementation package in one structured answer, including the full circuit/pin table, detailed wiring schematic, ESP32 Arduino code, n8n workflow JSON, AI-agent prompt, Telegram bot/voice workflow, Google Sheets setup, ThingSpeak configuration, HTML/CSS/JavaScript dashboard, database schema, flowcharts, sequence diagrams, BOM, installation steps, and final project-report format.
Absolutely. That is a strong structure for a final-year engineering/IoT/AI project report. I would expand it into the following complete documentation structure so that it works both as a technical implementation manual and as an academic project report.
AI Smart Pillow — Complete Project Documentation Structure
Project title:
AI Smart Pillow for Sleep Monitoring and Sleep-Event Detection using ESP32, IoT, n8n Automation, AI Agent, Telegram Voice Alerts, Google Sheets and ThingSpeak
1. Abstract
The abstract should briefly explain:
-
What the Smart Pillow is.
-
Why sleep monitoring is important.
-
Why ESP32 is used.
-
Which sensors are used.
-
How IoT connectivity works.
-
How n8n automates the system.
-
How the AI agent analyzes events.
-
How Telegram provides notifications.
-
How Google Sheets stores historical data.
-
How ThingSpeak provides visualization.
-
What the prototype can and cannot determine.
Example
This project presents an AI-enabled smart pillow designed for continuous sleep monitoring and detection of unusual sleep-related events. The system uses an ESP32 microcontroller together with multiple sensors to collect parameters such as movement, pressure distribution, environmental conditions, and acoustic events. The collected data is transmitted through Wi-Fi to an n8n automation server, where it is processed and analyzed using an AI agent. Based on predefined rules and sensor patterns, the system classifies events and can automatically record the data in Google Sheets, update a ThingSpeak cloud dashboard, and send text or voice notifications through Telegram. A web-based dashboard provides real-time monitoring and historical visualization. The proposed system demonstrates an agentic IoT architecture in which an embedded device collects information while cloud automation and AI perform higher-level event interpretation. The prototype is intended for experimental sleep monitoring and anomaly detection and is not a replacement for clinical sleep diagnosis.
2. Introduction
Explain the background of:
-
Sleep and sleep monitoring
-
Problems associated with poor sleep
-
Conventional sleep-monitoring systems
-
IoT-based healthcare/wellness systems
-
Embedded sensors
-
ESP32
-
Artificial intelligence
-
Agentic automation
-
Cloud dashboards
-
Telegram notifications
Suggested structure
2.1 Background
2.2 Sleep Monitoring
2.3 IoT in Healthcare
2.4 AI-Based Monitoring
2.5 Motivation
2.6 Proposed Approach
3. Problem Statement
Clearly identify the engineering problem.
Example
Conventional sleep-monitoring systems can involve expensive equipment, dedicated monitoring environments, or complicated interfaces. There is a need for a low-cost prototype capable of collecting multiple sleep-related signals in a comfortable environment and automatically processing those signals.
The proposed system attempts to solve this engineering problem by integrating:
Sensors
↓
ESP32
↓
Wi-Fi
↓
n8n
↓
AI Agent
↓
Cloud storage
↓
Dashboard
↓
Telegram notification
4. Objectives
Primary objective
Develop an IoT-enabled smart pillow capable of collecting and analyzing sleep-related sensor data.
Secondary objectives
-
Develop an ESP32-based sensor platform.
-
Monitor pillow pressure/movement.
-
Monitor environmental parameters.
-
Detect acoustic/sleep events where appropriate.
-
Transmit data over Wi-Fi.
-
Develop an n8n automation workflow.
-
Integrate an AI agent.
-
Store data in Google Sheets.
-
Display data using ThingSpeak.
-
Develop a web dashboard.
-
Send Telegram alerts.
-
Generate Telegram voice notifications.
-
Maintain historical sleep-session records.
-
Implement error handling and device recovery.
5. Existing-System Limitations
Discuss limitations without claiming that every commercial sleep product has the same limitations.
Possible areas:
-
Cost
-
Comfort
-
Limited customization
-
Lack of real-time alerts
-
Limited integration between IoT and AI
-
Limited user-controlled automation
-
Limited historical data access
-
Lack of open hardware/software architecture
Then clearly distinguish your prototype from clinical polysomnography and medically validated sleep devices.
6. Proposed System
Explain the complete proposed solution.
SMART PILLOW
│
▼
┌───────────┐
│ ESP32 │
└─────┬─────┘
│
Sensor data
│
▼
Wi-Fi/HTTP
│
▼
┌───────────┐
│ n8n │
└─────┬─────┘
│
AI Agent
│
┌──────────┼──────────┐
▼ ▼ ▼
Telegram Google ThingSpeak
Sheets
│
▼
Web Dashboard
7. System Architecture
Divide the architecture into four layers.
Layer 1 — Physical layer
Pressure
Motion
Temperature
Humidity
Audio/event sensor
│
▼
ESP32
Layer 2 — Communication layer
ESP32
│
└── Wi-Fi
│
├── HTTP
└── MQTT (optional)
Layer 3 — Intelligence/automation layer
n8n
│
├── Validation
├── Processing
├── Rules
├── AI Agent
└── Decision
Layer 4 — Application layer
Telegram
Google Sheets
ThingSpeak
Web Dashboard
8. Hardware Requirements
Create a complete Bill of Materials.
Example:
| Component | Quantity | Purpose |
|---|---|---|
| ESP32 DevKit | 1 | Main controller |
| Pressure sensors/FSRs | Multiple | Pillow pressure |
| MPU6050 | 1 | Motion/orientation |
| DHT22/SHT31 | 1 | Temperature/humidity |
| Microphone module | 1 | Acoustic events |
| Resistors | As required | Sensor circuits |
| Breadboard/PCB | 1 | Prototyping |
| Jumper wires | — | Connections |
| 5 V USB supply | 1 | Power |
| Pillow/foam enclosure | 1 | Mechanical integration |
The final BOM should include:
-
Part number
-
Quantity
-
Voltage
-
Current
-
Approximate price
-
Supplier
-
Purpose
9. Detailed Sensor Selection
For each sensor, document:
9.1 Sensor name
9.2 Operating voltage
9.3 Interface
For example:
I²C
SPI
UART
ADC
GPIO
9.4 Measurement range
9.5 Resolution
9.6 Accuracy
9.7 Why it was selected
9.8 Connection to ESP32
9.9 Calibration method
9.10 Limitations
10. ESP32 Pin Configuration
Create a table such as:
| ESP32 Pin | Device | Function |
|---|---|---|
| GPIO21 | I²C sensors | SDA |
| GPIO22 | I²C sensors | SCL |
| GPIO34 | Pressure sensor | ADC |
| GPIO35 | Pressure sensor | ADC |
| GPIO25 | Audio/event input | Digital/ADC |
| 3V3 | Sensors | Power |
| GND | Sensors | Ground |
The actual pins must be finalized after selecting the exact modules. Avoid assigning pins that conflict with bootstrapping, flash, or other ESP32-specific functions.
11. Circuit/Schematic
Include three diagrams:
11.1 Block schematic
ESP32
┌───────────┐
│ │
Pressure ───►│ ADC │
MPU6050 ────►│ I²C │
Temp ───────►│ I²C │
Audio ──────►│ ADC/GPIO │
│ │
│ Wi-Fi │
└─────┬─────┘
│
▼
n8n
11.2 Wiring diagram
Show:
VCC
GND
SDA
SCL
ADC
GPIO
11.3 Complete electrical schematic
This should eventually be created in:
-
KiCad
-
EasyEDA
-
Fritzing
-
Altium
-
Or another schematic tool.
12. Smart-Pillow Mechanical Arrangement
This section is particularly important.
Show where sensors physically sit.
Example:
TOP VIEW
┌─────────────────────────────┐
│ │
│ P1 P2 P3 │
│ │
│ │
│ ┌───────┐ │
│ │ HEAD │ │
│ │ AREA │ │
│ └───────┘ │
│ │
│ M1 M2 │
│ │
└─────────────────────────────┘
P1/P2/P3 = pressure sensing areas
M1/M2 = motion/event sensing
Document:
-
Sensor placement
-
Cushioning
-
Wiring channels
-
Electronics enclosure
-
Washable pillow cover
-
User comfort
-
Heat generation
-
Cable strain relief
-
Electrical isolation
13 . Firmware Architecture
setup()
│
├── Initialize GPIO
├── Initialize I²C
├── Initialize sensors
├── Load configuration
├── Connect Wi-Fi
└── Start timers
│
▼
loop()
│
├── Read sensors
├── Filter data
├── Detect events
├── Build JSON
├── Send telemetry
└── Handle errors
14. Complete ESP32 Source Code
The final documentation should contain:
main.ino
config.h
sensors.cpp
sensors.h
wifi_manager.cpp
wifi_manager.h
communication.cpp
communication.h
event_detector.cpp
event_detector.h
Instead of placing everything in one huge .ino file, modular code
makes the project easier to maintain.
15. Wi-Fi Communication
Document:
ESP32
│
│ SSID/password
▼
Wi-Fi router
│
▼
Internet
│
▼
n8n server
Include:
-
Connection procedure
-
Reconnection
-
Timeout
-
Authentication
-
TLS/HTTPS
-
Offline buffering
-
Retry mechanism
16. HTTP/M QTT Protocol
You can support either HTTP or MQTT.
HTTP
POST /webhook/smart-pillow
Content-Type: application/json
MQTT
Topic:
smartpillow/device01/telemetry
Payload:
{
"movement": 0.72,
"pressure": 61,
"temperature": 28.4
}
For a first prototype, HTTPS POST to an n8n webhook is simpler. MQTT becomes attractive when you have multiple devices or require continuous publish/subscribe telemetry.
17. JSON Data Format
Define a formal schema.
{
"device_id": "SMARTPILLOW_01",
"timestamp": "2026-09-29T21:30:00+05:30",
"sensors": {
"movement": 0.72,
"pressure_left": 61,
"pressure_center": 43,
"pressure_right": 18,
"temperature": 28.4,
"humidity": 61,
"sound_level": 68
},
"events": {
"movement_event": true,
"sound_event": true
}
}
18. n8n Installation
Document:
Install n8n
↓
Create credentials
↓
Create webhook
↓
Configure processing
↓
Configure AI
↓
Configure Telegram
↓
Configure Google Sheets
↓
Configure ThingSpeak
↓
Activate workflow
Also document whether n8n is running:
-
Locally
-
Docker
-
VPS
-
Cloud-hosted server
19. Complete n8n Workflow
The finished workflow should look approximately like:
Webhook
│
▼
Validate JSON
│
▼
Normalize Data
│
▼
Basic Rule Check
│
▼
AI Agent
│
┌─────┴─────┐
▼ ▼
Normal Alert
│ │
▼ ▼
Google Sheets Telegram
│ │
▼ ▼
ThingSpeak Voice Alert
The documentation should include screenshots of every important n8n node and its configuration.
20. AI-Agent Prompt and Logic
Document:
-
System prompt
-
Input schema
-
Output schema
-
Decision rules
-
Thresholds
-
Safety constraints
-
Error handling
Example:
INPUT
↓
Sensor observations
↓
Rule engine
↓
AI Agent
↓
Structured JSON
↓
Action router
The AI should not be instructed to diagnose a disease from these signals.
21. Telegram Bot Configuration
Document:
-
Create Telegram bot.
-
Obtain bot token.
-
Configure n8n credentials.
-
Obtain permitted chat ID.
-
Configure message node.
-
Test
/start. -
Test
/status. -
Test alert message.
Example:
/start
/status
/report
/events
22. Telegram Voice-Alert Pipeline
AI Agent
│
▼
Alert decision
│
▼
Generate natural-language message
│
▼
Text-to-Speech
│
▼
Audio file
│
▼
Telegram Bot
│
▼
User's phone
Example:
"Smart Pillow alert.
A repeated sleep disturbance was detected.
Please review the sleep-session data."
23. Google Sheets Integration
Columns:
Timestamp
Device ID
Session ID
Movement
Pressure
Temperature
Humidity
Sound
Event
Severity
AI Summary
Notification Sent
The documentation should explain:
-
Authentication
-
Spreadsheet creation
-
Column mapping
-
Append operation
-
Error handling
24. ThingSpeak Integration
Document :
ESP32/n8n
│
▼
ThingSpeak
│
├── Field 1: Movement
├── Field 2: Pressure
├── Field 3: Temperature
├── Field 4: Humidity
├── Field 5: Sound
├── Field 6: Event
└── Field 7: Alert level
Include screenshots of the resulting charts.
25. Web Dashboard
The dashboard can show:
┌──────────────────────────────────────────────┐
│ AI SMART PILLOW │
├──────────────────────────────────────────────┤
│ Device: 🟢 ONLINE │
│ Session: 01 │
│ │
│ Temperature 28.4 °C │
│ Humidity 61 % │
│ Movement 72 % │
│ Pressure 61 │
│ Sound event DETECTED │
│ │
│ ─────── Live Sensor Graph ─────────────── │
│ │
│ ─────── Event History ─────────────────── │
│ 02:17 Disturbance │
│ 03:06 Movement event │
└──────────────────────────────────────────────┘
26. Database/Data Model
Define:
Device
device_id
device_name
firmware_version
last_seen
status
Sleep session
session_id
device_id
start_time
end_time
Sensor record
record_id
session_id
timestamp
movement
pressure
temperature
humidity
sound
Event
event_id
session_id
timestamp
event_type
severity
ai_summary
notification_status
27. Flowcharts
Include at least:
System flowchart
START
↓
Initialize ESP32
↓
Initialize sensors
↓
Connect Wi-Fi
↓
Read sensors
↓
Process data
↓
Create JSON
↓
Send to n8n
↓
AI analysis
↓
Event?
┌┴─────┐
No Yes
│ │
▼ ▼
Log Alert
│ │
└───┬───┘
▼
Repeat
28. Sequence Diagrams
Normal operation
ESP32 n8n AI Sheets ThingSpeak
│ │ │ │ │
│──data────►│ │ │ │
│ │──data─►│ │ │
│ │◄─JSON──│ │ │
│ │────────────log────►│ │
│ │────────────────────────data──────►│
│ │ │ │ │
Alert operation
ESP32 → n8n → AI Agent
│
▼
Alert detected
│
┌─────┴─────┐
▼ ▼
Telegram Sheets
│
▼
Voice alert
29. Testing Methodology
Testing should cover:
Hardware testing
-
Sensor connectivity
-
Voltage
-
Current
-
ADC response
-
I²C communication
-
Wi-Fi stability
Software testing
-
JSON generation
-
Webhook reception
-
AI response
-
Google Sheets
-
ThingSpeak
-
Telegram
End-to-end testing
Sensor
↓
ESP32
↓
Wi-Fi
↓
n8n
↓
AI
↓
Cloud
↓
Telegram
30. Test Cases
Example:
| Test | Input | Expected result |
|---|---|---|
| T01 | Power ON | ESP32 boots |
| T02 | Wi-Fi available | Device connects |
| T03 | Wi-Fi disconnected | Reconnection attempted |
| T04 | Sensor movement | Movement value changes |
| T05 | Webhook request | n8n receives JSON |
| T06 | Normal data | Logged without alert |
| T07 | Alert condition | Telegram notification |
| T08 | Data record | Google Sheets updated |
| T09 | Telemetry | ThingSpeak updated |
| T10 | Telegram command | Bot responds |
31. Error Handling
Handle:
Sensor failure
Wi-Fi failure
Internet failure
n8n unavailable
AI API failure
Google Sheets failure
ThingSpeak failure
Telegram failure
Invalid JSON
Low power
ESP32 crash
Example:
Wi-Fi lost
↓
Retry connection
↓
Still unavailable?
↓
Store data locally
↓
Connection restored
↓
Upload buffered records
32. Security
This section is essential.
Include:
-
HTTPS
-
API-key protection
-
Telegram bot-token protection
-
Wi-Fi credential protection
-
n8n authentication
-
Access control
-
Secrets management
-
Input validation
-
Rate limiting
-
Secure OTA
-
No hard-coded production credentials
Never put real credentials in the published source code.
Use:
#define WIFI_SSID "..."
#define WIFI_PASSWORD "..."
#define N8N_TOKEN "..."
only in a private configuration file that is excluded from Git.
33. Privacy
The project may potentially process sensitive sleep-related information.
Document:
-
What data is collected
-
Why it is collected
-
Where it is stored
-
Who can access it
-
How long it is retained
-
Whether audio is stored
-
Whether raw sensor data leaves the device
-
How the user can delete the data
If audio is only used to calculate an event feature, consider processing it locally and transmitting features/events rather than raw audio.
34. Limitations
Be explicit.
Examples:
-
Prototype sensor accuracy
-
Pillow-position dependence
-
Individual differences
-
Limited training data
-
False positives
-
False negatives
-
Wi-Fi dependence
-
Cloud-service dependency
-
AI interpretation uncertainty
-
Lack of clinical validation
Most importantly:
The prototype should not be represented as a clinically validated diagnostic device or as proof that a user has a specific sleep disorder.
35. Future Improvements
Possible future versions:
ESP32-S3
↓
Edge AI
↓
TinyML model
↓
Local event detection
Other improvements:
-
Flexible pressure-sensor matrix
-
Better acoustic processing
-
Edge AI
-
Personalized sleep models
-
On-device anomaly detection
-
BLE connectivity
-
Battery operation
-
Low-power modes
-
Secure OTA
-
Mobile application
-
More sophisticated dashboard
-
Multi-user support
-
Long-term trend analysis
36. Cost/BOM
Final report should contain something like:
| Component | Qty | Estimated cost | Total |
|---|---|---|---|
| ESP32 | 1 | ₹___ | ₹___ |
| MPU6050 | 1 | ₹___ | ₹___ |
| Pressure sensors | ___ | ₹___ | ₹___ |
| Temperature sensor | 1 | ₹___ | ₹___ |
| Microphone | 1 | ₹___ | ₹___ |
| PCB/wires | — | ₹___ | ₹___ |
| Pillow enclosure | 1 | ₹___ | ₹___ |
| Power supply | 1 | ₹___ | ₹___ |
| Total | ₹___ |
Prices should be filled using the actual components you purchase rather than assumed values.
37. Installation Procedure
A good installation chapter should be reproducible by another student.
Step 1 → Assemble hardware
Step 2 → Flash ESP32 firmware
Step 3 → Configure Wi-Fi
Step 4 → Create n8n instance
Step 5 → Import workflow
Step 6 → Configure credentials
Step 7 → Create Telegram bot
Step 8 → Configure Google Sheets
Step 9 → Create ThingSpeak channel
Step 10 → Start dashboard
Step 11 → Power Smart Pillow
Step 12 → Verify telemetry
Step 13 → Test alert
Step 14 → Start sleep-session recording
38. Troubleshooting
Create a table:
| Problem | Possible cause | Solution |
|---|---|---|
| ESP32 doesn't boot | Power issue | Check 5 V/3.3 V |
| Sensor unavailable | Wiring | Check SDA/SCL |
| Wi-Fi fails | Credentials | Verify SSID/password |
| n8n receives nothing | Webhook/network | Test endpoint |
| Telegram doesn't alert | Bot credentials/chat ID | Verify credentials |
| Sheets not updating | Authentication | Reauthorize |
| Dashboard empty | Wrong channel/API | Check ThingSpeak configuration |
| AI output invalid | Prompt/API issue | Validate structured output |
39 . Results
This section should contain actual measured results, not expected results.
Recommended measurements:
Sensor performance
Pressure response
Movement response
Temperature stability
Sound/event detection
Communication performance
ESP32 → n8n latency
n8n processing time
Telegram notification latency
Cloud update interval
Reliability
24-hour test
Wi-Fi reconnection
Sensor failure recovery
Server failure recovery
Example result table
| Parameter | Measured result |
|---|---|
| ESP32 → n8n latency | ___ ms |
| Telegram alert latency | ___ sec |
| Wi-Fi reconnection | ___ sec |
| Sensor sampling rate | ___ Hz |
| Successful transmissions | ___ % |
| False alerts during test | ___ |
| Missed events | ___ |
40. Conclusion
The conclusion should summarize what was actually built and demonstrated.
A suitable conclusion would state that the project successfully demonstrates an integrated ESP32 + IoT + n8n + AI + cloud + Telegram architecture for experimental sleep monitoring, while clearly identifying the limitations of the prototype and the need for further validation before any medical application.
Recommended final project architecture
The complete project can ultimately be presented as:
AI SMART PILLOW
│
┌─────────┴─────────┐
│ │
SENSORS ESP32
│ │
└─────────┬─────────┘
│
Wi-Fi
│
▼
┌─────────────────┐
│ n8n WEBHOOK │
└────────┬────────┘
│
▼
┌─────────────────┐
│ DATA PROCESSING │
└────────┬────────┘
│
▼
┌─────────────────┐
│ AI AGENT │
└────────┬────────┘
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Google Sheets ThingSpeak Telegram
│ │ │
│ ▼ ▼
│ Cloud Graphs Text/Voice
│ │
└─────────────┬─────────────┘
▼
WEB DASHBOARD
│
▼
USER
This structure is suitable for turning the project into a full engineering report, implementation manual, GitHub README, viva presentation, and demonstration project rather than just a conceptual description.
🧠 AI Smart Pillow — Project Mind Map
┌──────────────────────────────┐
│ 🛏️ AI SMART PILLOW │
│ Sleep Monitoring + IoT AI │
└──────────────┬───────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
│ │ │
▼ ▼ ▼
🔧 HARDWARE 🧠 AI & SOFTWARE ☁️ CLOUD / IoT
│ │ │
┌─────┼─────┐ ┌─────┼─────┐ ┌─────┼─────┐
│ │ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
ESP32 Sensors Power Firmware n8n AI Agent Wi-Fi Sheets ThingSpeak
│ │ │ │ │
│ ├─ Pressure │ │ ├─ Event analysis
│ ├─ MPU6050 │ │ ├─ Classification
│ ├─ Temperature │ │ └─ Decision
│ ├─ Humidity │ │
│ └─ Audio/Event │ ├─ Webhook
│ │ ├─ Processing
└────────── GPIO/I²C/ADC ─────┘ ├─ Routing
└─ Automation
┌────────────────────────────────┐
│ 📡 DATA PIPELINE │
└───────────────┬────────────────┘
│
┌────────────────────────────┼────────────────────────────┐
▼ ▼ ▼
Sensor Data JSON Payload Timestamp
│ │ │
└────────────────────────────┼────────────────────────────┘
▼
┌─────────────┐
│ n8n │
└──────┬──────┘
▼
Data Validation
│
▼
AI Agent Analysis
│
┌───────────┼───────────┐
▼ ▼ ▼
NORMAL DISTURBANCE WARNING
│ │ │
└───────────┼───────────┘
▼
Action / Automation
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
Google Sheets ThingSpeak Telegram
│ │ │
▼ ▼ ▼
Historical Graphs Text Alert
Data │
▼
Voice Alert
🔩 Hardware Branch
AI Smart Pillow
│
└── Hardware
├── ESP32
│ ├── GPIO
│ ├── ADC
│ ├── I²C
│ └── Wi-Fi
│
├── Pressure Sensors
│ └── Pressure distribution
│
├── MPU6050
│ ├── Movement
│ └── Orientation
│
├── Temperature/Humidity
│
├── Microphone
│ └── Acoustic events
│
└── Power Supply
💻 Software Branch
Software
│
├── ESP32 Firmware
│ ├── Sensor drivers
│ ├── Calibration
│ ├── Filtering
│ ├── Event detection
│ ├── JSON generation
│ └── Wi-Fi communication
│
├── n8n
│ ├── Webhook
│ ├── Validation
│ ├── Data processing
│ ├── AI Agent
│ ├── IF / routing
│ └── Error handling
│
├── AI
│ ├── Sensor interpretation
│ ├── Event classification
│ ├── Severity
│ └── Notification decision
│
└── Web Dashboard
├── Live status
├── Sensor values
├── Event history
└── Graphs
📱 Notification Branch
AI Agent
│
▼
Alert Decision
│
├── No Alert
│
└── Alert
│
▼
Telegram
│
├── Text Message
│
└── Text-to-Speech
│
▼
Voice File
│
▼
User
☁️ Cloud/Data Branch
n8n
│
┌─────────┼─────────┐
▼ ▼ ▼
Google Sheets ThingSpeak Telegram
│ │ │
▼ ▼ ▼
Historical Charts Notifications
Records
🔐 Security & Privacy Branch
Security / Privacy
│
├── HTTPS
├── API authentication
├── Secret management
├── Telegram token protection
├── Wi-Fi credential protection
├── Input validation
├── Access control
├── Secure OTA
└── Data retention
🧪 Testing Branch
Testing
│
├── Hardware
│ ├── Sensor test
│ ├── Power test
│ └── ESP32 test
│
├── Communication
│ ├── Wi-Fi
│ ├── HTTP/MQTT
│ └── n8n webhook
│
├── AI
│ ├── Normal event
│ ├── Disturbance
│ └── Warning
│
├── Cloud
│ ├── Google Sheets
│ └── ThingSpeak
│
└── Telegram
├── Text
└── Voice
🚀 Future Development
Future
│
├── Edge AI / TinyML
├── ESP32-S3
├── Flexible pressure matrix
├── Better acoustic processing
├── Personalized models
├── Mobile application
├── Battery operation
├── Secure OTA
├── Long-term sleep trends
└── Clinical validation research
One-line mind map
🛏️ Smart Pillow
→ Sensors
→ ESP32
→ Wi-Fi
→ n8n
→ AI Agent
→ Decision
→ Google Sheets + ThingSpeak + Telegram
→ Voice Alert
→ Web Dashboard
→ Testing + Security + Privacy
→ Future AI/IoT Improvements
This gives you the complete high-level map from physical sensor → ESP32 → AI agent → automation → cloud → user notification.
No comments:
Post a Comment