Smart Cabinet - Case Study
This smart cabinet project delivers an embedded control solution for archival storage, combining real-time door monitoring, touchscreen status display, and dual-network cloud connectivity into a single compact unit. Built around an ESP32 microcontroller, the system detects open-door events, tracks duration, and triggers both local and remote alerts. This smart cabinet architecture remains extensible for future hardware variants and white-label deployments, supporting ongoing project development.
Smart Cabinet Project Context & Technical Requirements
The client required a smart control unit for an archival cabinet designed to detect when a door is left open, track the open duration, and trigger local and remote alerts. The device needed to support a 4”+ touchscreen display to show real-time status and countdown timers, while maintaining communication over both Ethernet and Wi-Fi.
A core requirement was a future-proof architecture: the initial version uses off-the-shelf ESP32 hardware to monitor basic inputs and outputs, but the firmware and custom PCB had to be engineered to allow easy expansion for white-label variants and remote MQTT (Message Queuing Telemetry Transport)-based control of heavier components (such as fans, heating plates, and compressors).
The development followed a structured phase approach: validation on a development board (PoC1 and PoC2), transition to custom PCB design, and final MVP deployment.
Smart Cabinet Project Context & Technical Requirements
The client required a smart control unit for an archival cabinet designed to detect when a door is left open, track the open duration, and trigger local and remote alerts. The device needed to support a 4”+ touchscreen display to show real-time status and countdown timers, while maintaining communication over both Ethernet and Wi-Fi.
A core requirement was a future-proof architecture: the initial version uses off-the-shelf ESP32 hardware to monitor basic inputs and outputs, but the firmware and custom PCB had to be engineered to allow easy expansion for white-label variants and remote MQTT (Message Queuing Telemetry Transport)-based control of heavier components (such as fans, heating plates, and compressors).
The development followed a structured phase approach: validation on a development board (PoC1 and PoC2), transition to custom PCB design, and final MVP deployment.
Hardware Stack
Firmware Stack
System Architecture & Implementation
The project development process was structured to isolate hardware risks early by proving out core features on development boards before laying out the custom PCB. The implementation focused on three architectural priorities:
Dual-Medium network failover logic
To ensure high availability in varied facility environments, the firmware treats Ethernet as the primary communication path and Wi-Fi as a hot-standby. Running on the ESP32, the network manager executes an independent state machine that monitors link integrity at both the physical and network layers. If the Ethernet link drops, the system initiates an immediate failover sequence to the hot-standby Wi-Fi connection, minimizing telemetry downtime. The MQTT client uses non-blocking sockets, ensuring that connection drops or handshakes do not stall the core business logic or the localized alarm triggers.
UI threading & local provisioning
Driving a 4″+ screen alongside dual network stacks can cause resource starvation on an MCU. Leveraging the ESP32’s dual-core architecture, the firmware isolates the UI rendering task on a dedicated core, separating it from the network and telemetry threads. This guarantees that timer countdowns and display updates remain fluid, and that high-priority interrupts, such as the fire alarm or position sensor inputs, are serviced immediately.
For deployment, the firmware includes a standalone provisioning mode. When unconfigured, the device spins up a local web server or BLE service, allowing field technicians to push Wi-Fi credentials and adjust alert thresholds securely through a basic web browser interface or mobile app.
Modular MQTT abstraction for hardware scaling
To support future product scaling, such as adding climate control systems (fans, heating plates, compressors), the application firmware layer is completely isolated from the underlying physical drivers. The system communicates via standard JSON payloads over MQTT with Thingsboard, utilizing an abstract relay and driver interface mapping layer.
This hardware-agnostic architecture ensures that when subsequent PCB revisions introduce new physical components, the core system state machine and cloud telemetry logic remain untouched. Integrating new hardware becomes a matter of expanding the software configuration mapping — a deliberate design decision that keeps ongoing project development lean and drastically reduces future time-to-market for white-label variants.
Project Duration Estimate
| Stage | Description | Min h | Max h |
|---|---|---|---|
|
Setup & Infrastructure |
Prepare repository, build environment, and validate basic ESP32 firmware structure and hardware abstraction layer. |
26 |
31 |
|
Connectivity & Config |
Implement initial Wi-Fi connectivity, position sensor, buttons, fire alarm input, buzzer, and basic Thingsboard MQTT connection. |
130 |
180 |
|
Interface & Fallback |
Integrate Ethernet interface with fallback connection logic to Wi-Fi, LCD driver framework, and local touch display UI. |
125 |
136 |
|
Proof of Concept (POC)
|
|
281
|
355
|
|
Hardware & Prototyping |
Design custom PCB schematic and layout supporting ESP32, Ethernet, power supply, and handle up to two hardware revisions. |
77 |
105 |
|
MVP Deployment |
Implement secure device provisioning (BLE/Wi-Fi AP mode), remote cloud control, secure webpage setup, and system optimization. |
117 |
152 |
|
MVP (with custom hardware)
|
|
194
|
257
|
|
Tester time |
|
48 |
62 |
|
Project management |
|
48 |
62 |
|
Total estimated time |
|
571 |
728 |
Risk Assessment
| Risk | Description | Min h | Max h |
|---|---|---|---|
|
Thingsboard Integration |
Documentation gaps, unexpected version changes, or custom server-side scripts required due to specific requirements. |
0
|
35 |
|
Dev Board Constraints |
Development board limitations requiring unexpected extra components or adjustments to the initial functional scope. |
0
|
11 |
|
LCD & HMI Complexity |
Higher complexity than anticipated during the design and implementation of the touch screen user interface. |
0
|
29 |
|
PCB Prototyping Volatility |
Unexpected layout routing issues or component complexities discovering during hardware revision cycles. |
0
|
22 |
|
Undocumented Hardware |
Unforeseen behavior or hardware bugs within the selected peripheral modules and silicon errata. |
0
|
18 |
|
Business Logic Shifts |
Mid-project updates or modifications to the core application rules and alarm control behaviors. |
0
|
26 |
|
Total estimated risk |
|
0
|
141
|
