Migration de MajorDoMo vers osysHome : guide étape par étape sans interruption

# Migration de la domotique domestique : Passage de MajorDoMo à osysHome sans interruption

Après huit ans d'utilisation de MajorDoMo comme plateforme principale de domotique domestique, l'auteur s'est heurté à une complexité de maintenance en pleine explosion. Toute modification de script nécessitait une chaîne de vérifications, transformant les tâches routinières en marathons du soir. Le passage à l'osysHome personnalisé a été motivé par une nécessité absolue — pour réduire la charge cognitive lors de la gestion du système. Cet article détaille un plan de migration étape par étape sans interruption, les principaux pièges et les tactiques applicables à toute configuration d'automatisation à grande échelle.

Pourquoi MajorDoMo ne convenait plus

Ce qui avait commencé comme un banc d'essai a évolué sur huit ans en un élément d'infrastructure critique. Le nombre d'objets a atteint 200, des capteurs physiques aux entités virtuelles et à la logique utilitaire. Les problèmes principaux étaient systémiques :

• Réponses d'automatisation plus lentes — les processus en arrière-plan ont commencé à se disputer les ressources
• Fragmentation des données — difficile de suivre les connexions entre objets
• Permissions opaques — configuration manuelle des droits pour chaque nouveau script
• Scripts fragiles — toute modification exigeait la vérification des dépendances

Le point de rupture était le piège du « petit ajustement » : un travail de 10 minutes qui gonflait routinièrement en heures de débogage. Pour des systèmes de cette échelle, les maux de tête de maintenance éclipsaient l'ajout de nouvelles fonctionnalités.

Stratégie de lancement parallèle

La plus grosse erreur de migration ? Tenter un « grand basculement ». Au lieu de cela, nous avons déployé un transfert progressif en gardant tout opérationnel à chaque étape :

• Lancement isolé d'osysHome — installé en parallèle de MajorDoMo sur le même matériel (SOYO M4 AIR N95 16GB+512GB sur Ubuntu Server 25.10)
• Vérification de l'intégration — tests manuels du contrôle des appareils via MQTT, Zigbee2MQTT et ESPHome
• Reconstruction du modèle d'objets — non pas en copiant, mais en réorganisant pour une maintenance à long terme plus aisée
• Duplication des automatisations — nouvelle logique mise en production seulement après confirmation de son bon fonctionnement

Cela a éliminé les risques d'arrêt complet. Un problème repéré ? Le système basculait automatiquement vers MajorDoMo, évitant les interventions d'urgence en pleine nuit.

Tactiques de migration des appareils

Les appareils ont été migrés par groupes fonctionnels, non par emplacement physique. Cela a réduit la charge mentale et accéléré le dépannage :

• Phase 1 : Infrastructure de base (broker MQTT, passerelle Zigbee)
• Phase 2 : Par type d'appareil (éclairage, climatisation, sécurité)
• Phase 3 : Écosystèmes complexes (Xiaomi avec aspirateur, lustre, humidificateur)

Les appareils Xiaomi ont été un casse-tête — leur API présentait des comportements imprévisibles qui ont consumé 30 % du temps de migration. Même le distributeur d'eau pour animaux, qui semblait simple, a pris deux soirées à cause des notifications asynchrones.

Victoires inattendues en cours de route

La migration a déclenché une refactorisation des parties obsolètes. En parallèle du déménagement, nous avons :

• Remplacé les relais Tasmota par ESPHome avec une interface unifiée
• Ajouté une passerelle Bluetooth pour les données des capteurs de température
• Converti les adaptateurs de compteurs Modbus vers un support natif
• Simplifié l'affichage du ticker défilant via MAX7219

Cela valait mieux qu'un simple portage. Éliminer la dette technique pendant la migration a réduit les coûts de support à long terme, même si cela a augmenté l'effort à court terme.

Les suites : Ce qui a changé après le passage

Les métriques personnelles ont montré une baisse des coûts d'exploitation :

• Temps d'édition réduit — de 2 heures à 15 minutes pour les scripts standards
• Permissions simplifiées — gestion centralisée des droits au lieu d'ajustements manuels
• Stabilité améliorée — plus de déclenchements faux grâce à un modèle d'objets plus propre

Cela dit, osysHome a ses limites. Les débutants peinent sans scripts prêts à l'emploi. La documentation accuse un retard sur la base de code, et certaines fonctionnalités (comme l'intégration ThinQ) nécessitent une configuration manuelle. Pour l'auteur, ces compromis valent la peine pour la réduction de la charge mentale.

Enseignements clés

• Les exécutions parallèles sont indispensables pour les systèmes sans interruption
• Le groupement fonctionnel accélère le débogage 2–3x par rapport aux dispositions physiques
• La migration est le moment idéal pour refactoriser les composants legacy
• La maintenabilité prime sur les fonctionnalités pour les systèmes de plus de 5 ans
• Prévoir 30 % de temps supplémentaire pour les appareils Xiaomi en raison des bizarreries de l'API

Le passage a pris deux semaines à raison de 2–3 heures par soir. Gros gain : plus d'appréhension devant les modifications de scripts. Les installations MajorDoMo stables n'en ont pas besoin, mais à mesure que la complexité augmente, un changement progressif prouve sa valeur. Leçon principale : choisir les plateformes en fonction de la maintenabilité à long terme, pas des spécifications.

— Editorial Team