More project photos (3)
The problem
In hospital wards, patients need a fast, reliable way to reach nurses, and nurses need to know exactly which bed is calling. Wired call-bell systems are expensive to retrofit into old buildings and give no record of how long a call waited — yet delayed response to a patient call is a genuine patient-safety concern. A wireless IoT call system solves both problems: every bed gets a simple button, the central console identifies the calling bed instantly, and call-to-response times are logged for shift review. This project builds that system at demonstration scale with ESP32 nodes — wireless alerting, central monitoring, acknowledgement workflow and logging — in a form students can extend toward real ward requirements.
Presses the bedside call button; pressing cancel clears the call.
Follow the working sequence
How it works
- The patient presses the bedside call button; the ESP32 wakes and transmits its configured bed ID.
- The message travels over Wi-Fi to the central unit (MQTT on the local network, or ESP-NOW link).
- The console LCD adds the bed to the active-call queue and the buzzer sounds.
- The nurse presses acknowledge on the console; the bedside lamp switches to the "nurse on the way" state.
- Both timestamps are written to the response log, viewable on the dashboard.
- Pressing cancel at the bedside clears the call; unacknowledged calls re-alert after the escalation timeout.
Tech stack:
- ESP32-WROOM-32 nodes (bedside units + central console)
- Wi-Fi with MQTT (local broker) or ESP-NOW link
- 16×2 LCD with I2C backpack on console
- Buzzer and beacon lamp for alerts
- Single-file HTML/CSS/JS dashboard served by central ESP32
- Arduino IDE firmware
- USB 5 V power; battery option for bedside units
| Parameter | Value |
|---|---|
| Nodes | Central console + 2–4 bedside units typical (configurable) |
| Link | Wi-Fi (local) or ESP-NOW; design target latency under 2 s |
| Range | Indoor Wi-Fi dependent, approx 10–30 m typical |
| Console display | 16×2 LCD with active-call queue |
| Alerts | Buzzer + beacon lamp; escalation re-alert configurable |
| Dashboard | Local web page; no internet or cloud needed |
| Power | USB 5 V; bedside units support battery option |
| Logging | Per-bed call/acknowledge timestamps |
| Status | Academic prototype — not certified medical equipment |
Project features
- [Wireless bedside call units] Battery/USB-powered ESP32 button units — one per bed — with a large illuminated call button and a cancel button.
- [Bed-number identification] Each unit carries a configured bed ID, so the console and dashboard show exactly which bed is calling.
- [Nurse-station console] Central ESP32 receiver with 16×2 LCD listing active calls in order, plus a buzzer and beacon lamp.
- [Acknowledgement workflow] The nurse acknowledges a call at the console (or from the dashboard); the bedside unit's lamp changes state to confirm.
- [Response-time logging] Call-raised and acknowledged timestamps are logged per bed for shift-level review.
- [Local Wi-Fi dashboard] A single-page web dashboard on the central unit shows live bed status without any cloud account.
- [Escalation timer] Calls unacknowledged beyond a configurable time re-alert with a distinct tone (configurable).
What is included
- Central nurse-station console (ESP32, LCD, buzzer, beacon)
- 2–4 wireless bedside call button units
- Complete firmware (nodes + console + dashboard)
- Circuit and wiring documentation
- Project report PDF (architecture, protocol, testing procedure, limitations)
- PPT presentation for final review
- Viva Q&A preparation document (ESP32, MQTT/ESP-NOW, IoT alerting)
- Setup and demonstration guide
Advantages
- Each bed gets a wireless ESP32 call unit with a large illuminated call button and a cancel button, replacing hardwired call points.
- Every unit carries a configured bed ID, so the console and dashboard show exactly which bed is calling.
- The nurse-station console lists active calls in order on a 16×2 LCD with a buzzer and beacon lamp, and acknowledgement changes the bedside lamp state to confirm.
- Call-raised and acknowledged timestamps are logged per bed for shift-level review of response times.
- A local Wi-Fi dashboard shows live bed status without any cloud account, and unacknowledged calls re-alert after a configurable escalation time.
Disadvantages
- This is an academic prototype only, not certified medical equipment, and it is not for life-critical or emergency use.
- Alert delivery depends on the local Wi-Fi environment, so dead zones and router outages affect it.
- Battery-powered bedside units need regular charging, and the dashboard's low-battery flag cannot prevent a flat battery.
- Response-time logs are only as disciplined as the acknowledgement workflow, and skipped acknowledgements skew the data.
- There is no encryption beyond standard Wi-Fi security, so patient-data handling is the deployer's responsibility.
Limitations & prerequisites
- Academic prototype only — not certified medical equipment and not for life-critical or emergency use; the disclaimer ships in the report and must stay in any presentation of the work.
- Alert delivery depends on the local Wi-Fi environment; dead zones and router outages affect it.
- Battery-powered bedside units need regular charging; the dashboard shows a low-battery flag but cannot prevent a flat battery.
- Response-time logs are only as disciplined as the acknowledgement workflow — skipped acknowledgements skew the data.
- No encryption beyond standard Wi-Fi security; patient-data handling is the deployer's responsibility.
Frequently Asked Questions
Which controller is used?
ESP32-WROOM-32 on every node and the central console, programmed in the Arduino IDE. Bedside units can use ESP32-C3 variants as a customization.
Does it need the internet?
No. The console, dashboard and logging all run on the local Wi-Fi network. Optional cloud push or SMS alerts can be added as customization.
How many beds can it cover?
The base build ships with 2–4 bedside units; more can be added since each unit just needs a unique bed ID — range and router capacity are the practical limits.
Can it be used in a real hospital?
No — it is an academic prototype demonstrating IoT alerting. Real deployment needs certified medical-device engineering, redundancy and compliance work far beyond this project.
What are the main limitations?
Wi-Fi dependence, battery charging discipline, prototype-grade (non-certified) status, and logs that depend on staff acknowledgement discipline.
Is this project suitable for a final-year project?
Yes — for IoT, Embedded Systems, Electronics and Computer programs. It demonstrates wireless sensor nodes, MQTT/ESP-NOW messaging, central monitoring and dashboard design. Suitable for B.E./B.Tech final-year projects in IoT, Embedded Systems and Electronics.
Components & software requirements
- ESP32-WROOM-32 nodes (bedside units + central console)
- Wi-Fi with MQTT (local broker) or ESP-NOW link
- 16×2 LCD with I2C backpack on console
- Buzzer and beacon lamp for alerts
- Single-file HTML/CSS/JS dashboard served by central ESP32
- Arduino IDE firmware
- USB 5 V power; battery option for bedside units
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.