El día en que mi cargador se volvió más lento sin decir nada

El síntoma

Instalación doméstica monofásica, garaje subterráneo, Tesla Model 3, carga nocturna fija a 32 A sin modulación solar y sin límite puesto en el coche. El cargador arranca a 32,6 A y calienta de forma continua. Cuando la temperatura de línea alcanza 79 °C espera 105 segundos, aplica un recorte único de 2,1 A y se queda ahí el resto de la sesión.

Tres propiedades que conviene anotar, porque determinan si eres capaz de detectar esto o no:

• El umbral es de 79 °C con unos 105 segundos de persistencia. No es un comparador instantáneo: una noche que roza el umbral sin sostenerlo no provoca recorte. Ese único dato explicó varias noches que yo había archivado como «inconsistentes».
• El recorte es discreto y de una sola vez: −2,1 A, −523 W, en una sola muestra. La temperatura responde en menos de un minuto y el sistema se estabiliza en equilibrio hacia los 76 °C.
• La configuración no se mueve nunca. max_charging_current y max_avbl_current siguen en 32 A todo el rato, el instante del recorte incluido.

Fechar el cambio

Mi recuerdo era «al principio funcionaba bien, y un día empezó, y así se quedó». Un recuerdo no es una prueba, así que: el cargador guarda una tabla session con dos años completos de historial, muchísimo más de lo que retiene el búfer de telemetría viva. La potencia media por sesión es una métrica burda —incorpora el tapering del propio coche cuando la batería se llena— pero es perfectamente válida para comparar sesiones equivalentes entre sí.

Una caída del 10 % y, después, quince meses completamente planos. Esa forma importa más que la magnitud: una resistencia de contacto degradándose por ciclado térmico daría un deslizamiento gradual. Un escalón que aterriza y se mantiene más de un año es un cambio de parámetro, no una pieza desgastándose.

Lo que el cargador registró en esa ventana

La tabla de errores es la única del dispositivo con marcas de tiempo utilizables tan atrás. Entre la última sesión buena y la primera mala contiene exactamente cuatro entradas, y cada una es el reinicio simultáneo de todos los servicios del equipo.

Un doble ciclo de reinicio en un minuto, con un evento de driver encajado entre ambos, es exactamente el aspecto que tiene una actualización de firmware remota vista desde dentro.

Mi hipótesis de trabajo es que el umbral se bajó deliberadamente por seguridad: el tipo de cambio que un fabricante despliega en silencio cuando los datos de campo empiezan a mostrar unidades funcionando más calientes de lo que le gustaría. Encaja con la forma de la evidencia mejor que cualquier modo de fallo que se me ocurra, y tiene una implicación incómoda: si eso es lo que pasó, no hay nada que reparar. La unidad está haciendo exactamente lo que se le ha mandado hacer.

Lo que no es

Cada una de estas fue una hipótesis viva en algún momento, y cada una costó mediciones matarla. Dejar constancia de los callejones sin salida es justamente el sentido de una nota de campo.

• No es la temperatura ambiente. En abril, con el garaje a unos 15 °C, la unidad llegaba igualmente a 81—83 °C. En septiembre, con 28,5 °C de ambiente, llega a 79 °C. El calentamiento propio del equipo, de +50 a +60 °C sobre ambiente a 32 A, domina por completo. Esta me sorprendió de verdad: daba por hecho que el disparador era el verano.
• No es un límite del coche. charge_current_request y charge_current_request_max leen ambos 30 A: el vehículo pide exactamente lo que el cargador le ofrece por el piloto de control, sin límite propio.
• No es un piloto de control cacheado. Esta es sutil y merece el aviso. Un coche que se ha quedado con un valor de piloto antiguo se parece mucho —corriente por debajo del máximo configurado—, pero la firma está invertida: con un piloto cacheado, la corriente sube mientras sube la temperatura. Aquí el recorte sigue a la temperatura. Mismo síntoma, causa opuesta, y el arreglo de uno es inútil contra el otro.
• No aparece en el registro de errores. La tabla de errores del dispositivo no contiene ningún código de sobretemperatura en toda su vida.

Lo que cuesta

Sesiones desde entonces

136

Energía entregada

3003 kWh

Horas de carga

635

Sobrecoste en tiempo

~58 h

Esas 58 horas son la diferencia entre entregar esa energía al nivel anterior y hacerlo al actual. En una noche normal son unos 30 minutos: molesto, no doloroso. El coste de verdad está en la cola de la distribución: en la peor noche registrada el recorte bajó hasta 18,3 A, y eso convierte una carga completa en un asunto de todo el día.

Cómo comprobar el tuyo

Nada de esto es visible desde la app del fabricante ni desde su API en la nube, así que todo salió del propio dispositivo. El Pulsar Plus corre Linux embebido y hay trabajo previo excelente para conseguir una shell de root y para sacar su estado por MQTT. Si quieres repetir las mismas mediciones en tu unidad, empieza por aquí — que quede claro: no escribí ninguno de los dos.

Con una shell, el estado interesante vive en una base de datos MySQL local llamada wallbox. Dos tablas contienen todo lo usado en este artículo:

-- telemetria viva: temp_l1, ac_current_rms_l1, max_charging_current...
-- buffer circular, 25k filas, unos 2,5 meses
SELECT timestamp, temp_l1, ac_current_rms_l1, max_charging_current
FROM state_values ORDER BY timestamp DESC LIMIT 50;

-- historial de sesiones: esta si guarda anos
SELECT DATE(start_time)              AS dia,
       ROUND(energy/1000, 1)         AS kwh,
       ROUND(charging_time/60)       AS minutos,
       ROUND(energy*3.6/charging_time, 2) AS kw_medio
FROM session
WHERE HOUR(start_time) IN (23, 0)   -- solo sesiones nocturnas
  AND charging_time > 7200          -- mas de dos horas
  AND energy > 15000
ORDER BY start_time;

Por el lado de MQTT, los topics que quieres son wallbox_<serie>/temp_l1/state y wallbox_<serie>/charging_current_l1/state. Registra los dos con resolución de unos pocos segundos durante una sesión completa y la escalera se dibuja sola. Si además pasas el coche por TeslaMate, cruza charge_current_request_max del MQTT y no la columna charger_pilot_current de Postgres: esta última reportaba 16 A contra 30 A de corriente medida en mi coche, que es físicamente imposible, y me costó otro camino equivocado.

Cómo está la cosa

Sin resolver, siendo honesto. El umbral está caracterizado, el cambio está fechado en una ventana de cuatro meses, y el mecanismo detrás de esa ventana sigue siendo una inferencia. Hay dos cosas en la cola.

La primera es aburrida y probablemente funcione: convección forzada. Un ventilador de 120 mm, un relé inteligente, un soporte impreso en 3D y una automatización que lo arranque por encima de 60 °C mientras carga. Si la unidad no llega nunca a 79 °C, nunca recorta, sea cual sea el umbral que lleve el firmware. He hecho un par de sesiones con la tapa físicamente abierta y siguen tocando el umbral, lo cual es indicativo pero está muy lejos de ser noches suficientes para dar por muerta la convección natural. En cualquier caso, mover aire es un régimen físico distinto, y ese es el que merece probarse en serio.

La segunda es pedir al fabricante el historial de firmware de la unidad y ver si esa ventana coincide con un despliegue. Vaya como vaya esa respuesta, la parte interesante ya está hecha: el dispositivo registró su propia regresión, en dos tablas distintas, y la guardó durante dos años. Estaba ahí todo el tiempo, detrás de un formato de fecha que no cuadraba y de un campo de configuración que no se mueve nunca.

Cuando el ventilador esté puesto, la prueba es sencilla y los datos para comparar ya existen: que la corriente de línea aguante 32,6 A una sesión entera, en vez de bajar un escalón en el minuto veintitrés.