Airwell IoT Router
Abstraction Layer for IoT Devices
Overview
Context
Airwell is a climate control company offering IoT devices (air conditioning, thermostats, sensors) controlled via mobile app. To connect devices from multiple manufacturers, the company used a third-party service acting as an intermediary. The problem: recurring licensing costs per device, vendor lock-in, additional latency, and inability to customize without depending on the supplier.
Solution
Currently the company uses a third-party external API to connect devices, generating high monthly costs. The IoT Router is an abstraction layer that connects directly to manufacturer device APIs, normalizes different formats into a unified API, maintains compatibility with the legacy mobile app's expected format, and scales to support new manufacturers via a plugin system. The solution will eliminate these costs and give the company complete technological independence.
My Role
I took over a project started by an Amiltone colleague and performed a massive refactoring, defining best practices and adapting the architecture to scale. I designed the plugin architecture for multiple manufacturers, developed a distributed rate limiting system with Redis, and integrated AWS Lambda for scheduled commands. I also made interventions in Airwell's standard API server to integrate the IoT Router, and performed complete debugging of the React Native mobile app which wasn't working - identifying issues and sending reports to the team.
Tech Stack
Frontend
Backend
Projects
IoT Router
Multi-Manufacturer Plugin System + Scheduled Commands
Abstraction layer with plugin architecture for integration with multiple IoT manufacturers. Each manufacturer is an isolated module implementing a common interface. Includes scheduled command system via AWS Lambda + Bull Queue with automatic retry.
Features
Plugin Architecture
Extensible system where each manufacturer is an isolated plugin implementing IPartnerPlugin
Discovery Handler
Automatic device discovery per user per manufacturer with metadata extraction
Data Handler
Status reading, measurements (temperature, humidity, CO2) with unit normalization
Command Handler
Command execution (on/off, temperature adjustment) with automatic retry
Scheduled Commands
AWS EventBridge + Lambda + Bull Queue for scheduled commands with exponential retry
OAuth 2.0 Flow
Complete authentication flow with automatic refresh of encrypted tokens
Rate Limiting
Sliding window algorithm in Redis with custom rules per manufacturer
Adapter Pattern
Data transformation from manufacturer format to normalized mobile-compatible format
Configuration as Code
Partner and device configuration via YAML validated by JSON Schema
Entity Loaders
Repository pattern encapsulating data access with optimized queries
Interceptors & Guards
Structured logging and consistent error handling throughout the application
Design Patterns
Technical Decisions
Redis for Rate Limiting
Distributed, persistent, precise sliding window, reused for Bull queues
Bull Queue vs AWS SQS
Already have Redis, monitoring UI (Bull Board), less latency than SQS
AES-256-GCM in Database
Operational simplicity vs dedicated Vault, sufficient for the use case
Challenges & Solutions
Heterogeneous APIs
Plugin pattern isolates complexity - each plugin speaks the manufacturer's 'language'
Complex Rate Limiting
Per-manufacturer configuration + Redis sliding window + metrics for fine-tuning
Legacy Mobile Compatibility
Adapter pattern normalizes responses to format expected by legacy app
Scheduled Commands
AWS EventBridge → Lambda → Bull Queue with exponential retry and auditing