“Lo barato cuesta caro” suena a refrán de abuelo… hasta que te toca armar un proyecto de medición y control y descubres que el problema no fue el software, ni el dashboard, ni el protocolo.
Fue una decisión previa, silenciosa: la selección del hardware.
Me pasa seguido en terreno (y especialmente cuando el cliente pide una cotización de servicio de medición eléctrica). En ese momento aparece una frase que se repite:
“Ahora nos dimos cuenta que ahorramos donde no debíamos”.
¿El síntoma? No es que el equipo “no prenda”. Es peor: no puedes sostener el proyecto en el tiempo, porque cuando vas a buscar la información técnica…
-
no existe,
-
es deficiente,
-
o directamente confirma que el equipo no sirve para control y medición.
Y ahí se entiende el costo real del “barato”.
Por qué la documentación importa más de lo que parece
En proyectos eléctricos, a veces se compra con la lógica de “cumple y listo”: mide algo, entrega un número, y parece suficiente.
Pero un proyecto de medición y control no vive de “un número”. Vive de evidencia:
-
que el dato sea consistente,
-
que el origen sea trazable,
-
que sea estable bajo operación real,
-
que puedas explicar un pico, una caída o un “hueco” sin entrar en suposiciones.
Y eso empieza por algo básico: documentación usable.
La documentación no es “papel bonito”. Es lo que te permite responder preguntas como:
-
¿qué variable estoy leyendo exactamente?
-
¿en qué unidad, con qué escala y con qué orden de palabras?
-
¿qué condiciones de instalación y comunicación garantizan estabilidad?
-
¿qué eventos o diagnósticos me ayudan a detectar fallas antes de que el cliente las sufra?
Si esas respuestas no existen, el proyecto queda condenado a “funcionar a ratos”.
Señales rojas en medidores: cuando el dato es una apuesta
Hay medidores que se venden como “compatibles” o “inteligentes”, pero al momento de integrarlos te das cuenta de que el soporte técnico es una sombra.
Señales típicas de riesgo:
1) No hay especificación clara de precisión y uso
Si no puedes saber con qué confiabilidad mide energía bajo diferentes condiciones, estás comprando una “lectura”, no una medición defendible.
2) El mapa de registros es ambiguo o inconsistente
Sin un mapa bien definido (variables, direcciones, tipo de dato, escala, unidades), el equipo puede responder… y aun así estar entregando valores mal interpretados. Lo peligroso es que se ven “reales”.
3) No hay trazabilidad de versiones
Si un firmware cambia y el comportamiento cambia (registros, escalas, eventos), necesitas saberlo. Si no hay control de versiones ni notas claras, cada actualización se vuelve una ruleta.
4) No existe diagnóstico mínimo
En operación real, necesitas distinguir:
“el proceso cambió” vs “la comunicación falló” vs “el mapeo está mal” vs “el medidor está saturado”.
Sin señales de estado, todo termina en discusiones internas y tickets eternos.
Resultado: el dato deja de ser un activo. Se vuelve un “tema”.
Señales rojas en gateways y comunicaciones: cuando el sistema depende de la suerte
El gateway es el puente entre el mundo físico y tu sistema. Si ese puente es frágil, el mejor software del mundo solo va a mostrar una verdad incómoda: no hay continuidad.
Señales que he visto repetir:
1) No está pensado para operación real (24/7)
Reinicios, microcortes, temperaturas, ruido, vibración, ambientes hostiles. Si el equipo está diseñado “para laboratorio”, lo sabrás cuando empiecen los vacíos de datos.
2) No existe estrategia de continuidad del dato
Cuando la conectividad cae, ¿se pierde todo? ¿se recupera? ¿queda evidencia?
Si el gateway no maneja bien esa realidad, el proyecto mide “cuando se puede”, no cuando se necesita.
3) La comunicación se trata como detalle
En terreno, los problemas de comunicación rara vez se presentan como “error claro”. Se presentan como intermitencias, timeouts, lecturas incompletas. Y eso erosiona lo más valioso: la confianza.
Cuando tu cliente deja de confiar en el dato, el proyecto deja de valorizarse. Aunque el dashboard se vea bonito.
El costo real: pagar dos veces (y retrasar el ROI)
Aquí es donde el refrán se vuelve contabilidad.
Cuando el hardware elegido no tiene respaldo técnico, el costo aparece más tarde y por todos lados:
-
reemplazo de medidores,
-
recambio o refuerzo de gateways/comunicaciones,
-
horas de ingeniería para “adivinar” lo que no está documentado,
-
visitas a terreno no planificadas,
-
reconfiguración, pruebas, re-etiquetado,
-
y una pérdida silenciosa: el proyecto queda “en duda” frente a gerencia/operaciones.
Entonces sí: lo barato cuesta caro.
Porque no solo pagas de nuevo el hardware. Pagas con tiempo, reputación y con el retraso del valor que ibas a capturar.
Un criterio simple: si no hay evidencia técnica, no hay control
Antes de elegir medidores y gateways, más que preguntar “¿cuánto cuesta?” conviene preguntar “¿qué me permite demostrar?”.
Aquí van 6 preguntas que suelen evitar la doble compra:
-
¿Existe documentación técnica completa y coherente (no un PDF genérico)?
-
¿Está claro qué variables entrega, en qué unidades y con qué escalas?
-
¿Hay trazabilidad de versiones (firmware / revisiones) y cambios documentados?
-
¿Incluye señales de diagnóstico / eventos para detectar fallas y no culpar al sistema?
-
¿El gateway está pensado para operación continua y continuidad del dato en condiciones reales?
-
¿Hay soporte técnico real (y verificable) cuando algo no calza en terreno?
No son preguntas “de marca”. Son preguntas de criterio.
Si te llevas una idea, que sea esta: el primer indicador de calidad en medidores y gateways no es el precio, es la evidencia técnica que los sostiene.
En tu experiencia, ¿cuál ha sido el “barato sale caro” más común: documentación inexistente, comunicaciones inestables, o datos que se veían bien pero estaban mal?
