# Migración de Domótica: Cambio de MajorDoMo a osysHome Sin Tiempo de Inactividad
Después de ocho años ejecutando MajorDoMo como la principal plataforma de domótica, el autor se topó con un muro ante la complejidad de mantenimiento disparada. Cualquier ajuste en un script requería una cadena de verificaciones, convirtiendo tareas rutinarias en maratones vespertinos. El cambio a osysHome, construido a medida, fue impulsado por pura necesidad: reducir la carga cognitiva al gestionar el sistema. Este artículo desglosa un plan de migración paso a paso sin interrupciones, errores clave y tácticas aplicables a cualquier configuración de automatización a gran escala.
Por Qué MajorDoMo Dejó de Ser Suficiente
Lo que empezó como un banco de pruebas evolucionó durante ocho años hasta convertirse en una pieza clave de infraestructura crítica. El número de objetos alcanzó los 200, desde sensores físicos hasta entidades virtuales y lógica de utilidades. Los problemas principales eran sistémicos:
- Respuestas de automatización más lentas — los procesos en segundo plano empezaron a competir por recursos
- Fragmentación de datos — difícil rastrear conexiones entre objetos
- Permisos opacos — configuración manual de derechos para cada nuevo script
- Scripts frágiles — cualquier edición exigía verificar dependencias
El punto de quiebre fue la trampa del «pequeño ajuste»: una tarea de 10 minutos que rutinariamente se inflaba a horas de depuración. Para sistemas de esta escala, los dolores de cabeza en mantenimiento eclipsaban la adición de nuevas funciones.
Estrategia de Lanzamiento en Paralelo
¿El mayor error en una migración? Intentar un «gran cambio». En su lugar, implementamos una entrega por fases manteniendo todo en marcha en cada paso:
- Lanzamiento aislado de osysHome — instalado junto a MajorDoMo en el mismo hardware (SOYO M4 AIR N95 16GB+512GB en Ubuntu Server 25.10)
- Verificación de integración — pruebas manuales del control de dispositivos vía MQTT, Zigbee2MQTT y ESPHome
- Reconstrucción del modelo de objetos — no copiando, sino reorganizando para un mantenimiento a largo plazo más fácil
- Duplicación de automatizaciones — la nueva lógica solo se activaba tras confirmar que funcionaba
Esto eliminó riesgos de caídas totales. ¿Detectas un problema? El sistema revertía automáticamente a MajorDoMo, evitando alarmas nocturnas.
Tácticas de Migración de Dispositivos
Los dispositivos se movieron por grupos funcionales, no por ubicación física. Esto redujo la carga mental y aceleró la resolución de problemas:
- Fase 1: Infraestructura básica (MQTT broker, gateway Zigbee)
- Fase 2: Por tipo de dispositivo (iluminación, climatización, seguridad)
- Fase 3: Ecosistemas complejos (Xiaomi con aspiradora, lámpara de techo, humidificador)
Los dispositivos Xiaomi fueron un dolor de cabeza: su API tenía comportamientos peculiares que consumieron el 30% del tiempo de migración. Incluso el bebedero para mascotas, que parecía sencillo, tomó dos noches por las notificaciones asíncronas.
Victorias Inesperadas en el Camino
La migración impulsó una refactorización de partes obsoletas. Junto con el traslado, hicimos:
- Cambiamos relés Tasmota por ESPHome con una interfaz unificada
- Añadimos un gateway Bluetooth para datos de sensores de temperatura
- Convertimos adaptadores de medidores Modbus a soporte nativo
- Optimizamos la pantalla de ticker deslizante vía MAX7219
Esto superó una simple transferencia directa. Limpiar la deuda técnica durante la migración redujo los costos de soporte a largo plazo, aunque aumentó el esfuerzo a corto plazo.
El Después: Qué Cambió Tras el Cambio
Métricas personales mostraron una caída en costos operativos:
- Tiempo de edición reducido — de 2 horas a 15 minutos para scripts estándar
- Permisos simplificados — gestión centralizada de derechos en lugar de ajustes manuales
- Estabilidad mejorada — adiós a disparos falsos gracias a un modelo de objetos más limpio
Dicho esto, osysHome tiene límites. Los novatos luchan sin scripts listos para usar. La documentación va por detrás del código, y algunas funciones (como la integración con ThinQ) requieren configuración manual. Para el autor, estos compromisos compensan con una menor carga mental.
Lecciones Clave
- Ejecuciones en paralelo son imprescindibles para sistemas sin interrupciones
- Agrupación funcional acelera la depuración 2–3 veces frente a disposiciones físicas
- La migración es el momento ideal para refactorizar componentes heredados
- La mantenibilidad prima sobre las funciones en sistemas de más de 5 años
- Presupuesta un 30% extra de tiempo para dispositivos Xiaomi por rarezas de su API
El cambio tomó dos semanas a 2–3 horas por noche. Gran victoria: ya no hay pavor ante ediciones de scripts. Configuraciones estables de MajorDoMo no lo necesitan, pero al crecer la complejidad, un cambio gradual demuestra su valor. Lección principal: elige plataformas por mantenibilidad a largo plazo, no por especificaciones.
— Editorial Team
Aún no hay comentarios.