Multi-modal inputs
Supports wheelchair-context detection, NFC, mobile app trigger, assistive switch input, and proximity wave-to-open modes.
Hands-Free Door Access
A safe, multi-modal door activation system for users who can’t press the accessible door button.
Accessibility / Assistive Tech / Embedded SystemsReference build
Problem
Some users cannot reliably press a wall plate or accessibility button even when automatic doors are available.
The control path must be hands-free, dependable, and safety-aware, with minimal false activation risk and no disruption to existing door controls.
Key Features
Safety logic
Includes debounce, cooldown, and confirmation windows with explicit state transitions.
Non-invasive integration
Relay wiring is designed in parallel with existing push-button contacts so current behavior is preserved.
Logging support
Provides local event logging with optional cloud-sheet export for monitoring workflows.
Configurable modes
Profiles can be tuned for home, clinic, or high-traffic operating conditions.
Privacy-preserving operation
Supports no-camera mode with sensor and assistive-input pathways when required.
System Architecture
The hub is organized around provisioning, device control, MQTT messaging, and firmware lifecycle management so the system stays understandable as more devices are added.
System Architecture
Input adapters route user intent through safety logic before relay activation.
State Machine
Idle, detect, confirm, trigger, and cooldown transitions designed for safer activation behavior.
Parallel Relay Wiring
Relay path is wired in parallel so existing accessible button operation remains intact.
Hardware & Software Stack
| MCU | ESP32 |
|---|---|
| Inputs supported | NFC, app trigger, assistive switch, proximity modes |
| Output type | Relay contact (parallel trigger path) |
| Installation mode | Parallel with existing accessible button |
| Logging | Local logs + optional Google Sheets export |
| Connectivity | BLE / Wi-Fi (config dependent) |
How It Works
1. Detect intent
Input arrives from configured sources such as NFC, assistive switch, app trigger, or proximity channel.
2. Confirm
Safety logic checks confirmation window and optional multi-signal gating before actuation.
3. Activate relay
Relay closes in parallel with existing button input to request door opening.
4. Log and cooldown
Event is recorded and cooldown timer enforces spacing before the next trigger attempt.
Safety & Reliability
The design keeps safety and reliability visible through low-voltage-first testing, controlled relay behavior, and firmware recovery thinking.
Safety controls
- Debounce and confirmation windows reduce transient trigger risk.
- Cooldown prevents rapid repeated activations.
- Manual override path remains available through original button hardware.
False activation mitigation
- Threshold and timing logic gate uncertain detections.
- Optional multi-signal confirmation can be enabled per deployment mode.
- Time-based gating limits unintended re-trigger behavior.
Test plan
- Bench tests planned for trigger latency and repeatability.
- False-open rate tracking planned under noisy-input scenarios.
- Cooldown and recovery behavior planned for fault-injection checks.
OTA Update Flow
The OTA firmware update system is designed around staged delivery, integrity checks, and rollback-safe recovery so maintenance does not become the weak point of the platform.
- Cooldown and gating logic constrain repeated activations.
- State transitions are explicit to support deterministic behavior checks.
- Design supports iterative firmware hardening for deployment contexts.
Validation & Testing
Validation focused on onboarding flow stability, reconnect behavior, and rollback-safe maintenance so the design holds up beyond a demo-only prototype.
Validation Focus
- Bench-focused validation plan includes latency and false-open tracking.
- Failure-path checks include noisy input and cooldown enforcement scenarios.
- Logging schema supports post-run analysis for safety refinement.
Build Resources
Supporting artifacts for architecture review, collaboration, and follow-up implementation planning.
FAQ
Will it break the existing door button?
No. The relay path is designed in parallel so the original accessible button continues to function.
How do you prevent accidental opens?
The logic uses debounce, confirmation windows, and cooldown timing, with optional multi-signal gating.
Can it work without a camera?
Yes. NFC, assistive switch, app trigger, and proximity-only modes can be used in no-camera configurations.
Does it store personal data?
Logging is event-focused and can be configured to minimize stored personal data according to deployment policy.
What door systems is this compatible with?
This reference design targets systems that accept a dry-contact style trigger path similar to accessible push-button interfaces.
Need help building or extending a smart-device prototype?
Get support with architecture, firmware structure, validation, and production-minded IoT design.