Airwell IoT Router
Couche d'Abstraction pour Appareils IoT
Aperçu
Contexte
Airwell est une entreprise de climatisation proposant des appareils IoT (climatiseurs, thermostats, capteurs) contrôlés via application mobile. Pour connecter les appareils de plusieurs fabricants, l'entreprise utilisait un service tiers comme intermédiaire. Le problème : coûts récurrents de licence par appareil, vendor lock-in, latence supplémentaire, et impossibilité de personnaliser sans dépendre du fournisseur.
Solution
Actuellement l'entreprise utilise une API externe tierce pour connecter les appareils, générant des coûts mensuels élevés. L'IoT Router est une couche d'abstraction qui se connecte directement aux APIs des fabricants d'appareils, normalise les différents formats en une API unifiée, maintient la compatibilité avec le format attendu par le mobile legacy, et permet d'ajouter de nouveaux fabricants via un système de plugins. La solution va éliminer ces coûts et donner une indépendance technologique totale à l'entreprise.
Mon Rôle
J'ai repris un projet initié par un collègue d'Amiltone et réalisé un refactoring massif, définissant les bonnes pratiques et adaptant l'architecture pour scaler. J'ai conçu l'architecture de plugins pour plusieurs fabricants, développé un système de rate limiting distribué avec Redis, et intégré AWS Lambda pour les commandes planifiées. J'ai également fait des interventions sur l'API server standard d'Airwell pour intégrer l'IoT Router, et réalisé un debugging complet de l'app mobile React Native qui ne fonctionnait pas - identifiant les problèmes et envoyant des rapports à l'équipe.
Stack Technique
Frontend
Backend
Projets
IoT Router
Système de Plugins Multi-Fabricant + Commandes Planifiées
Couche d'abstraction avec architecture de plugins pour l'intégration avec plusieurs fabricants IoT. Chaque fabricant est un module isolé implémentant une interface commune. Inclut système de commandes planifiées via AWS Lambda + Bull Queue avec retry automatique.
Fonctionnalités
Plugin Architecture
Système extensible où chaque fabricant est un plugin isolé implémentant IPartnerPlugin
Discovery Handler
Découverte automatique des appareils par utilisateur et fabricant avec extraction de métadonnées
Data Handler
Lecture de statut, mesures (température, humidité, CO2) avec normalisation des unités
Command Handler
Exécution de commandes (on/off, ajustement température) avec retry automatique
Scheduled Commands
AWS EventBridge + Lambda + Bull Queue pour commandes planifiées avec retry exponentiel
OAuth 2.0 Flow
Flux d'authentification complet avec refresh automatique des tokens chiffrés
Rate Limiting
Algorithme sliding window dans Redis avec règles personnalisées par fabricant
Adapter Pattern
Transformation des données du format fabricant vers format normalisé compatible mobile
Configuration as Code
Configuration des partenaires et appareils via YAML validé par JSON Schema
Entity Loaders
Repository pattern encapsulant l'accès aux données avec queries optimisées
Interceptors & Guards
Logging structuré et gestion d'erreurs cohérente dans toute l'application
Design Patterns
Décisions Techniques
Redis pour Rate Limiting
Distribué, persistant, sliding window précis, réutilisé pour files Bull
Bull Queue vs AWS SQS
On a déjà Redis, UI de monitoring (Bull Board), moins de latence que SQS
AES-256-GCM en Base
Simplicité opérationnelle vs Vault dédié, suffisant pour le cas d'usage
Défis & Solutions
APIs Hétérogènes
Plugin pattern isole la complexité - chaque plugin parle la 'langue' du fabricant
Rate Limiting Complexe
Configuration par fabricant + sliding window Redis + métriques pour ajustement fin
Compatibilité Mobile Legacy
Adapter pattern normalise les réponses au format attendu par l'app ancienne
Commandes Planifiées
AWS EventBridge → Lambda → Bull Queue avec retry exponentiel et audit