Tiempo de carga completa VE

Qué calcula el modelo y por qué el tramo final es más lento

Travel.ev_time_to_full responde a una pregunta práctica: desde el estado de carga que tiene ahora, cuánto tarda el paquete en reportar el cien por ciento con este cargador. La respuesta por tanto separa constant_phase_hours y taper_phase_hours para que pueda explicar por qué los últimos diez o veinte puntos de SOC dominan el tiempo de sesión en postes de alta potencia, y por qué muchos planificadores de ruta prefieren partir cerca del ochenta por ciento cuando los minutos importan más que el llenado absoluto.

Entradas, valores por defecto, validación y lectura de la respuesta

La efficiency opcional por defecto es cero coma nueve y debe situarse en el intervalo mayor que cero hasta uno inclusive. Tres campos son obligatorios y deben ser números finitos: battery_kwh (capacidad útil del paquete, estrictamente mayor que cero), soc_percent (estado de carga actual de cero a cien inclusive; se aceptan los alias current_soc y soc) y charger_kw (potencia de pico del cargador en kilovatios, estrictamente mayor que cero). El taper_start_percent opcional por defecto es ochenta y debe estar entre cero y cien. El taper_end_factor opcional por defecto es cero coma dos y debe ser mayor que cero y como máximo uno: si fuera cero, la integral divergiría al llegar la potencia al eje en el llenado. Cuando el SOC ya es cien, la capacidad devuelve cero horas y minutos con already_full en true en lugar de inventar una sesión negativa. Cualquier otro fallo lanza un error tipado invalid_input que nombra el campo culpable; la validación fallida no se factura. En caso de éxito recibe las entradas eco, energy_needed_kwh, constant_phase_hours, taper_phase_hours, horas totales, minutos totales (derivados del total de horas sin redondear antes del redondeo de presentación), already_full y una cadena corta de fórmula que documenta el modelo integral. Combine las cifras con su propio modelo térmico o de química de batería solo si necesita curvas específicas del vehículo; este endpoint se mantiene deliberadamente simple en cargador y paquete para que un formulario, un bot SMS o una API de flota puedan llamarlo sin mapas BMS propietarios.

Dónde el tiempo hasta el llenado con taper aporta valor en carretera y en software

La carga nocturna en casa con un wallbox de siete coma cuatro u once kilovatios suele planificarse frente a una hora de salida fija: los conductores quieren saber si, al enchufar al veinte por ciento tras una llegada tardía, el coche llega al llenado por la mañana una vez contado el taper final. Como la implementación es parse puro de nivel A, no hay tokens de modelo, no hay red saliente y no hay reloj ni azar dentro del manejador: solo aritmética que puede probar unitariamente para siempre. Los planificadores de paradas en viaje por carretera usan el mismo endpoint al decidir si esperar al noventa y cinco o al cien por ciento en un cargador rápido de corriente continua o desconectar cerca del ochenta y seguir, porque la fase de taper en un poste de cincuenta, ciento cincuenta o trescientos cincuenta kilovatios puede costar más minutos que la fase constante que llenó el medio del paquete. El software de flota de depósito y de empresa agrupa miles de llamadas a $0.002 cada una para programar relevos de turno cuando cada vehículo debe salir con un estado de carga completo documentado y no con un repostaje parcial. Use los valores por defecto para una primera estimación sensata, luego ajuste taper_start_percent y taper_end_factor cuando tenga telemetría de una familia concreta de vehículo y cargador, y conserve el desglose de energía y fases junto al total para que los operadores entiendan dónde se fueron los minutos.