Cuando sumé dos cámaras IP al servidor casero, asumí que integrarlas a Home Assistant iba a ser cuestión de poner una IP y una contraseña. No fue así, y el motivo por el que no lo fue termina siendo una buena metáfora de un problema mucho más general en DevOps: integrar hardware o software que no controlas casi nunca es un problema de configuración. Es un problema de protocolo.
La Reolink: cuando el límite no es de software
La primera cámara era una Reolink a batería. Traté de conectarla como cualquier dispositivo ONVIF o RTSP local, revisando puertos, credenciales, firmware. Nada funcionaba, y por una razón simple que tardé más de la cuenta en aceptar: ese modelo no expone ningún servidor local. Para ahorrar batería, la cámara solo negocia con la nube del fabricante cuando detecta movimiento; no hay stream RTSP que interceptar porque nunca existió. No era un bug ni un ajuste mal puesto — era una decisión de diseño del hardware, y ninguna cantidad de configuración en Home Assistant iba a cambiar eso. La lección aquí es simple pero se olvida seguido: antes de perder tiempo depurando una integración, conviene confirmar que el otro lado realmente habla el protocolo que uno espera.
La cámara genérica: sí hablaba, pero en otro idioma
La segunda cámara, una marca genérica tipo iCSee, sí tenía un servidor local activo — pero no en un protocolo estándar. Hablaba DVRIP, un protocolo propietario típico de DVRs chinos, por el puerto 34567. Home Assistant no tiene idea de qué es eso, y no la va a tener nunca: no es un protocolo abierto ni ampliamente soportado.
Acá es donde el problema deja de ser de infraestructura pura y se convierte en uno de desarrollo: no se trataba de configurar algo existente, sino de construir la pieza que faltaba. La solución fue go2rtc, un pequeño servidor que sabe hablar decenas de protocolos de cámaras (incluido DVRIP) y los re-expone como RTSP estándar, WebRTC o MJPEG. Corre como un contenedor Docker más, aislado, con una configuración así de directa:
streams:
camara_patio:
- dvrip://usuario:[email protected]:34567
Home Assistant nunca se entera de que detrás hay DVRIP. Solo ve un stream RTSP normal que sale del contenedor de go2rtc. El protocolo raro queda encapsulado en una capa intermedia, exactamente como se encapsula un servicio legacy detrás de una API cuando no se puede (o no conviene) tocar el sistema original.
El patrón detrás de las dos cámaras
Puestas una junto a la otra, las dos cámaras muestran los dos escenarios reales con los que uno se topa integrando sistemas de terceros:
- El límite es real y no se puede rodear (la Reolink): ahí la respuesta correcta es aceptar el límite y usar la vía que el fabricante sí ofrece, en este caso su nube, en vez de insistir con una integración local imposible.
- El límite es solo de protocolo (la cámara genérica): ahí el trabajo es escribir o desplegar una capa de traducción, y Docker hace que esa capa sea barata de aislar y desechable si deja de servir.
Esta distinción se aplica igual de bien a un servidor casero que a infraestructura corporativa: cuando una integración con un proveedor externo no funciona, la primera pregunta no es "¿qué configuré mal?" sino "¿esto es una limitación de hardware/licencia, o es un protocolo distinto que alguien ya tradujo?". La cantidad de proyectos open source pequeños dedicados exclusivamente a traducir un protocolo propietario a uno estándar —go2rtc, mqtt bridges, exporters de Prometheus para sistemas legacy— es enorme, y muchas veces resuelven en una tarde algo que de otro modo terminaría en meses de tickets con soporte del fabricante.
Al final, ninguna de las dos cámaras me hizo perder el tiempo por ser "mala tecnología". Me lo hizo perder no distinguir, desde el principio, en cuál de los dos escenarios estaba parado.